You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Andrey Chernyshev <a....@gmail.com> on 2006/07/04 16:38:50 UTC
[drlvm] Removing classlib-related tasks from VM build (was Doing the minimum to support Java 5 classfiles)
> 4) Change the drlvm build so that its deploy tree layout has no classlib
> files in it. So we can do ...
As a first step, I suggest that we make drlvm build completely free
from the classlib-related tasks and files, this may help to avoid
further confusion. For example, it doesn't have to copy things like
icu, seralizer, xalan e.t.c. - they are already taken from pre-built
class libraries. If there are no objections, I'm going to submit a
patch which will remove some of that stuff from vm build.
As a last step, one would remove the copying of the classlib binaries
(e.g. deploy.copy_classlib) after we have a top-level build in place.
Thanks,
Andrey.
On 6/23/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 23 June 2006 at 17:10, Tim Ellison <t....@gmail.com> wrote:
> > Rana Dasgupta wrote:
> > > On 6/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> > >> >>Pavel Pervov wrote:
> > >> >> Geir,
> > >> >>
> > >> >> What's the first thing we do?
> > >> >> I'd suggest switching the build to 1.5.
> > >> >>
> > >> >> The rest will come shortly :)
> > >>
> > >> >Now that's a plan! :)
> > >
> > >
> > > Hi Geir,
> > > Actually what Pavel says makes sense. Not sure what plan we need. We could
> > > do it either way. We can make some changes to the class structure, loader,
> > > and the jit/interpreter, and submit a couple of patches. It is not the
> > > "huge" patch that you have mentioned .. 7-8 files or so. Or we can switch
> > > the build first. This will break drlvm for a short time, and we can
> > > submit a
> > > couple of bug fixes to get it going again. This way, we will just add the
> > > minimum needed for removing the compiler hack. Whatever way you think makes
> > > sense.
> > > However, you started this thread with saying "no patch over the wall"
> > > and making this "learning exercise about DRLVM". Where are you going with
> > > this? Do you want to actually enumerate/discuss which source files need to
> > > change and in what way, on this thread so that more people can participate?
> > >
> > > Marginally confused :-)
> > > Rana
> >
> > Just for the record, my goal was to avoid 'moving the goalposts' for
> > drlvm to integrate with the classlib and run the tests, apps, etc.
> >
> > If consensus here is that moving to 5.0 (and thereby delaying that goal)
> > is more desirable then I'm happy to go along with it, though I'm keen to
> > get the entire end-to-end story working soonest.
> >
> > Regards,
> > Tim
>
> My feeling at the moment is that although drlvm and classlib are working
> together[0], it is evident[1] that things are not really integrated.
> I would prefer to see "real integration" before we break[0] things by
> moving to 5.0.
>
> As Geir pointed out recently, we are not just a Class library project,
> so perhaps a change of focus is warranted? Perhaps if we can agree a
> set of prerequisite goals (involving our JVMs) for moving to 5.0, we can
> ... err ... encourage this change of focus?
>
> My prerequisite goals would include things like:
>
> 1) Fix the (reasonable) 'hacks' that help us get this far with drlvm
> integration - e.g. the static libhyprt.a for instance.[2]
>
> 2) Implement enough of the classlibadapter kernel classes such that
> JCHEVM will run 'ant rebuild' in classlib[3]. We have some difficult
> problems (thread attach) but there is also a lot of low hanging fruit in
> terms of missing or incomplete methods.
>
> 3) Get drlvm loading with the Harmony launcher from Classlib so we
> can have both drlvm and IBM VME around for testing. I think this is
> important because it will make it easier for people to test with either
> JVM.
>
> 4) Change the drlvm build so that its deploy tree layout has no classlib
> files in it. So we can do ...
>
> 5) Create the top-level build that can combine the trimmed drlvm deploy
> tree and the classlib deploy tree to produce a working jdk. (In much
> the same way that we currently combine the classlib and IBM VME.)
>
> 6) Pull out shared dependencies to top-level so we only need one copy.
>
>
> At the moment, I think moving to 5.0 would increase the divide between
> the JVMs and Classlib.
>
> In the meantime there is still plenty of work to do for those that, for
> whatever reasons, don't find these tasks exciting enough - for instance,
> the missing java.lang.Character/java.lang.Math methods[4].
>
> Regards,
> Mark.
>
> [0] Thanks Geir!
>
> [1] http://issues.apache.org/jira/browse/HARMONY-651
>
> [2] This isn't a criticism; I think these hacks can be justified.
>
> [3] I tried this the other day. It got to the second (non-comment) line
> of the first ant script before crashing because ClassLoader.getResources()
> isn't implemented yet.
>
> [4] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_lang
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing
the minimum to support Java 5 classfiles)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Andrey Chernyshev wrote:
> On 7/4/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>>
>> Andrey Chernyshev wrote:
>> >> 4) Change the drlvm build so that its deploy tree layout has no
>> classlib
>> >> files in it. So we can do ...
>> >
>> > As a first step, I suggest that we make drlvm build completely free
>> > from the classlib-related tasks and files, this may help to avoid
>> > further confusion.
>>
>> I don't quite see what you mean. We need to use things from classlib to
>> build, like headers.
>
> I have created HARMONY-753 to illustrate what I mean :)
> Some of the things, like icu libraries, are copied twice at the moment -
> one time along with classlib binaries "bulk copy" (target
> "deploy.copy_classlib") and once more with the
> make/components/extra/icu4c.xml for example.
> I'm just suggesting to remove those tasks which are obsoleted by the
> fact that
> we are now using the complete classlib binaries.
Great. Got it.
>
>>
>> > For example, it doesn't have to copy things like
>> > icu, seralizer, xalan e.t.c. - they are already taken from pre-built
>> > class libraries.
>>
>> When you say "taken from pre-built class libraries" do you mean
>> "pre-build libraries"?
>>
>> Yes, we don't have to copy those - we really should organize a top level
>> dependency tree. I think I posted a note summarizing where we were last
>> week.
>>
>> > If there are no objections, I'm going to submit a
>> > patch which will remove some of that stuff from vm build.
>> >
>> > As a last step, one would remove the copying of the classlib binaries
>> > (e.g. deploy.copy_classlib) after we have a top-level build in place.
>>
>> I think I know what you mean, but I think that we still want this
>> option, so that someone could remain working in the drlvm directory.
>> IOW, there's no harm leaving it, and the top level build will just tell
>> drlvm to build itself into a canonical tree for copying by the top
>> level, and finding classlib is up to the top level builder.
>>
>> Note to self - we'll need to pass the location of the classlib to the
>> drlvm as a parameter with a top-level builder...
>
> I believe CLASSLIB_HOME env. variable can be used for that, right?
> One note - it currently used to point to the CLASSLIB root in a source
> tree, but may be it makes sense to have it pointing directly to the
> classib binaries.
We do need header files.
>
> BTW: drlvm build has a built-in machinery to get the resources from
> Internet. Do you think it may make sense to teach it to get the
> classlib binaries snapshots from the web site?
NO!
> I think
> remote.CLASSLIB.archive variable in win/lnx.properties can be used
> for that purpose, we only need to specify there the binaries location
> instead of source tree url.
No. You should be able to go get it yourself, unpack somewhere, and
point the variable.
>
> One of the issues here is that VM may not always work with the latest
> class libraries, hence hardcoding of the specific classlib snapshot
> URL/version in *.properties may be helpful (in the past SVN revision
> was used for that purpose).
Right
geir
>
> Thanks,
> Andrey.
>
>
>>
>> geir
>>
>>
>> >
>> > Thanks,
>> > Andrey.
>> >
>> >
>> > On 6/23/06, Mark Hindess <ma...@googlemail.com> wrote:
>> >>
>> >> On 23 June 2006 at 17:10, Tim Ellison <t....@gmail.com> wrote:
>> >> > Rana Dasgupta wrote:
>> >> > > On 6/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> >> > >> >>Pavel Pervov wrote:
>> >> > >> >> Geir,
>> >> > >> >>
>> >> > >> >> What's the first thing we do?
>> >> > >> >> I'd suggest switching the build to 1.5.
>> >> > >> >>
>> >> > >> >> The rest will come shortly :)
>> >> > >>
>> >> > >> >Now that's a plan! :)
>> >> > >
>> >> > >
>> >> > > Hi Geir,
>> >> > > Actually what Pavel says makes sense. Not sure what plan we need.
>> >> We could
>> >> > > do it either way. We can make some changes to the class structure,
>> >> loader,
>> >> > > and the jit/interpreter, and submit a couple of patches. It is not
>> >> the
>> >> > > "huge" patch that you have mentioned .. 7-8 files or so. Or we can
>> >> switch
>> >> > > the build first. This will break drlvm for a short time, and we
>> can
>> >> > > submit a
>> >> > > couple of bug fixes to get it going again. This way, we will just
>> >> add the
>> >> > > minimum needed for removing the compiler hack. Whatever way you
>> >> think makes
>> >> > > sense.
>> >> > > However, you started this thread with saying "no patch over the
>> >> wall"
>> >> > > and making this "learning exercise about DRLVM". Where are you
>> >> going with
>> >> > > this? Do you want to actually enumerate/discuss which source files
>> >> need to
>> >> > > change and in what way, on this thread so that more people can
>> >> participate?
>> >> > >
>> >> > > Marginally confused :-)
>> >> > > Rana
>> >> >
>> >> > Just for the record, my goal was to avoid 'moving the goalposts' for
>> >> > drlvm to integrate with the classlib and run the tests, apps, etc.
>> >> >
>> >> > If consensus here is that moving to 5.0 (and thereby delaying that
>> >> goal)
>> >> > is more desirable then I'm happy to go along with it, though I'm
>> >> keen to
>> >> > get the entire end-to-end story working soonest.
>> >> >
>> >> > Regards,
>> >> > Tim
>> >>
>> >> My feeling at the moment is that although drlvm and classlib are
>> working
>> >> together[0], it is evident[1] that things are not really integrated.
>> >> I would prefer to see "real integration" before we break[0] things by
>> >> moving to 5.0.
>> >>
>> >> As Geir pointed out recently, we are not just a Class library project,
>> >> so perhaps a change of focus is warranted? Perhaps if we can agree a
>> >> set of prerequisite goals (involving our JVMs) for moving to 5.0,
>> we can
>> >> ... err ... encourage this change of focus?
>> >>
>> >> My prerequisite goals would include things like:
>> >>
>> >> 1) Fix the (reasonable) 'hacks' that help us get this far with drlvm
>> >> integration - e.g. the static libhyprt.a for instance.[2]
>> >>
>> >> 2) Implement enough of the classlibadapter kernel classes such that
>> >> JCHEVM will run 'ant rebuild' in classlib[3]. We have some difficult
>> >> problems (thread attach) but there is also a lot of low hanging
>> fruit in
>> >> terms of missing or incomplete methods.
>> >>
>> >> 3) Get drlvm loading with the Harmony launcher from Classlib so we
>> >> can have both drlvm and IBM VME around for testing. I think this is
>> >> important because it will make it easier for people to test with
>> either
>> >> JVM.
>> >>
>> >> 4) Change the drlvm build so that its deploy tree layout has no
>> classlib
>> >> files in it. So we can do ...
>> >>
>> >> 5) Create the top-level build that can combine the trimmed drlvm
>> deploy
>> >> tree and the classlib deploy tree to produce a working jdk. (In much
>> >> the same way that we currently combine the classlib and IBM VME.)
>> >>
>> >> 6) Pull out shared dependencies to top-level so we only need one copy.
>> >>
>> >>
>> >> At the moment, I think moving to 5.0 would increase the divide between
>> >> the JVMs and Classlib.
>> >>
>> >> In the meantime there is still plenty of work to do for those that,
>> for
>> >> whatever reasons, don't find these tasks exciting enough - for
>> instance,
>> >> the missing java.lang.Character/java.lang.Math methods[4].
>> >>
>> >> Regards,
>> >> Mark.
>> >>
>> >> [0] Thanks Geir!
>> >>
>> >> [1] http://issues.apache.org/jira/browse/HARMONY-651
>> >>
>> >> [2] This isn't a criticism; I think these hacks can be justified.
>> >>
>> >> [3] I tried this the other day. It got to the second (non-comment)
>> line
>> >> of the first ant script before crashing because
>> >> ClassLoader.getResources()
>> >> isn't implemented yet.
>> >>
>> >> [4]
>> >>
>> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_lang
>>
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing
the minimum to support Java 5 classfiles)
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> I'm -1 for adding any more auto-fetches to DRLVM.
me too, for the record.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing
the minimum to support Java 5 classfiles)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Andrey Chernyshev wrote:
> On 7/5/06, Salikh Zakirov <Sa...@intel.com> wrote:
>> Mark Hindess wrote:
>> > Salikh Zakirov wrote:
>> >> Using the fixed classlib snapshot will remove one factor
>> >> of uncertainty, and will make the DRLVM behaviour more reproducible.
>> >
>> > -1
>> >
>> > Doing this will hide issues that appear when changes to classlib breaks
>> > drlvm. At this stage in the project, I'd rather have such issues be as
>> > visible as possible. Such breakages should be relatively easy to fix
>> > and any drlvm developer should be capable of rolling back classlib svn
>> > until things are fixed if they get impatient.
>> >
>> > I don't see how it significantly affects reproducibility since it is
>> > trivial to check/record the versions of classlib and drlvm svn when an
>> > error occurs?
>>
>> I agree that recording revision numbers of both classlib and drlvm
>> will be
>> sufficient to reproduce the problem.
>>
>> The hard part is finding the "good" ones when the latest revisions
>> do not work, in a case when someone wants to work on something different
>> than fixing the latest breakages.
>>
>> I think that the reasonable compromise is to have both capabilities in
>> the
>> build system (build with classlib snapshot or with latest checkout), and
>> leave it up to contributors to decide which way to use.
>
> One more idea - we have a web page with the classlib snapshots over here:
> http://people.apache.org/dist/incubator/harmony/snapshots/ with an
> option of downloading the latest classlib snapshot, or a snapshot at a
> fixed date.
> By default, drlvm build could use just the latest one. This will allow
> to catch the possible classlib/drlvm integration issues at the
> frequency of creating build snapshots. On the other hand, in case the
> latest classlib appears to be incompatible with vm, people can easily
> change the link and use any of previous snapshots. How does that
> sound?
I'm -1 for adding any more auto-fetches to DRLVM.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing the minimum to support Java 5 classfiles)
Posted by Andrey Chernyshev <a....@gmail.com>.
On 7/5/06, Salikh Zakirov <Sa...@intel.com> wrote:
> Mark Hindess wrote:
> > Salikh Zakirov wrote:
> >> Using the fixed classlib snapshot will remove one factor
> >> of uncertainty, and will make the DRLVM behaviour more reproducible.
> >
> > -1
> >
> > Doing this will hide issues that appear when changes to classlib breaks
> > drlvm. At this stage in the project, I'd rather have such issues be as
> > visible as possible. Such breakages should be relatively easy to fix
> > and any drlvm developer should be capable of rolling back classlib svn
> > until things are fixed if they get impatient.
> >
> > I don't see how it significantly affects reproducibility since it is
> > trivial to check/record the versions of classlib and drlvm svn when an
> > error occurs?
>
> I agree that recording revision numbers of both classlib and drlvm will be
> sufficient to reproduce the problem.
>
> The hard part is finding the "good" ones when the latest revisions
> do not work, in a case when someone wants to work on something different
> than fixing the latest breakages.
>
> I think that the reasonable compromise is to have both capabilities in the
> build system (build with classlib snapshot or with latest checkout), and
> leave it up to contributors to decide which way to use.
One more idea - we have a web page with the classlib snapshots over here:
http://people.apache.org/dist/incubator/harmony/snapshots/ with an
option of downloading the latest classlib snapshot, or a snapshot at a
fixed date.
By default, drlvm build could use just the latest one. This will allow
to catch the possible classlib/drlvm integration issues at the
frequency of creating build snapshots. On the other hand, in case the
latest classlib appears to be incompatible with vm, people can easily
change the link and use any of previous snapshots. How does that
sound?
Thanks,
Andrey.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing
the minimum to support Java 5 classfiles)
Posted by Tim Ellison <t....@gmail.com>.
Vladimir Gorr wrote:
> On 7/5/06, Salikh Zakirov <Sa...@intel.com> wrote:
>>
>> Mark Hindess wrote:
>> > Salikh Zakirov wrote:
>> >> Using the fixed classlib snapshot will remove one factor
>> >> of uncertainty, and will make the DRLVM behaviour more reproducible.
>> >
>> > -1
>> >
>> > Doing this will hide issues that appear when changes to classlib breaks
>> > drlvm. At this stage in the project, I'd rather have such issues be as
>> > visible as possible. Such breakages should be relatively easy to fix
>> > and any drlvm developer should be capable of rolling back classlib svn
>> > until things are fixed if they get impatient.
>> >
>> > I don't see how it significantly affects reproducibility since it is
>> > trivial to check/record the versions of classlib and drlvm svn when an
>> > error occurs?
>>
>> I agree that recording revision numbers of both classlib and drlvm
>> will be
>> sufficient to reproduce the problem.
>>
>> The hard part is finding the "good" ones when the latest revisions
>> do not work, in a case when someone wants to work on something different
>> than fixing the latest breakages.
>>
>> I think that the reasonable compromise is to have both capabilities in
>> the
>> build system (build with classlib snapshot or with latest checkout), and
>> leave it up to contributors to decide which way to use.
>
>
>
>
> If DRLVM will be built with the class library snapshot we should be sure it
> doesn't already contain the breakages.
>
> It means the responsible person for the class library snapshot should run
> the VM tests at least. IMO this will complicate
>
> the build process due to the possible test failures because it's not clear
> on this stage where a cause of error is.
>
>
>
> Therefore I'd prefer to build from scratch using the recent sources. In the
> case if any problems happen
>
> we can take any other revision either class library or DRLVM sources and
> re-build them if there are any doubts.
>
> In any case you need to take the latest version and to check it when you
> are
> finally going to commit your changes.
I agree, we have to keep these things working together, and carefully
manage the interface between VM and class library to allow for such
forward compatibility.
Downloading a particular snapshot/revision of classlib to work against
is not a good idea IMHO.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing the minimum to support Java 5 classfiles)
Posted by Anton Luht <an...@gmail.com>.
Hello,
For those who're going to rewrite the build: please add copying
logging.properties:
http://issues.apache.org/jira/browse/HARMONY-789
On 7/5/06, Vladimir Gorr <vv...@gmail.com> wrote:
> On 7/5/06, Salikh Zakirov <Sa...@intel.com> wrote:
> >
> > Mark Hindess wrote:
> > > Salikh Zakirov wrote:
> > >> Using the fixed classlib snapshot will remove one factor
> > >> of uncertainty, and will make the DRLVM behaviour more reproducible.
> > >
> > > -1
> > >
> > > Doing this will hide issues that appear when changes to classlib breaks
> > > drlvm. At this stage in the project, I'd rather have such issues be as
> > > visible as possible. Such breakages should be relatively easy to fix
> > > and any drlvm developer should be capable of rolling back classlib svn
> > > until things are fixed if they get impatient.
> > >
> > > I don't see how it significantly affects reproducibility since it is
> > > trivial to check/record the versions of classlib and drlvm svn when an
> > > error occurs?
> >
> > I agree that recording revision numbers of both classlib and drlvm will be
> > sufficient to reproduce the problem.
> >
> > The hard part is finding the "good" ones when the latest revisions
> > do not work, in a case when someone wants to work on something different
> > than fixing the latest breakages.
> >
> > I think that the reasonable compromise is to have both capabilities in the
> > build system (build with classlib snapshot or with latest checkout), and
> > leave it up to contributors to decide which way to use.
>
>
>
>
> If DRLVM will be built with the class library snapshot we should be sure it
> doesn't already contain the breakages.
>
> It means the responsible person for the class library snapshot should run
> the VM tests at least. IMO this will complicate
>
> the build process due to the possible test failures because it's not clear
> on this stage where a cause of error is.
>
>
>
> Therefore I'd prefer to build from scratch using the recent sources. In the
> case if any problems happen
>
> we can take any other revision either class library or DRLVM sources and
> re-build them if there are any doubts.
>
> In any case you need to take the latest version and to check it when you are
> finally going to commit your changes.
>
> Thanks,
> Vladimir.
>
>
> ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing the minimum to support Java 5 classfiles)
Posted by Vladimir Gorr <vv...@gmail.com>.
On 7/5/06, Salikh Zakirov <Sa...@intel.com> wrote:
>
> Mark Hindess wrote:
> > Salikh Zakirov wrote:
> >> Using the fixed classlib snapshot will remove one factor
> >> of uncertainty, and will make the DRLVM behaviour more reproducible.
> >
> > -1
> >
> > Doing this will hide issues that appear when changes to classlib breaks
> > drlvm. At this stage in the project, I'd rather have such issues be as
> > visible as possible. Such breakages should be relatively easy to fix
> > and any drlvm developer should be capable of rolling back classlib svn
> > until things are fixed if they get impatient.
> >
> > I don't see how it significantly affects reproducibility since it is
> > trivial to check/record the versions of classlib and drlvm svn when an
> > error occurs?
>
> I agree that recording revision numbers of both classlib and drlvm will be
> sufficient to reproduce the problem.
>
> The hard part is finding the "good" ones when the latest revisions
> do not work, in a case when someone wants to work on something different
> than fixing the latest breakages.
>
> I think that the reasonable compromise is to have both capabilities in the
> build system (build with classlib snapshot or with latest checkout), and
> leave it up to contributors to decide which way to use.
If DRLVM will be built with the class library snapshot we should be sure it
doesn't already contain the breakages.
It means the responsible person for the class library snapshot should run
the VM tests at least. IMO this will complicate
the build process due to the possible test failures because it's not clear
on this stage where a cause of error is.
Therefore I'd prefer to build from scratch using the recent sources. In the
case if any problems happen
we can take any other revision either class library or DRLVM sources and
re-build them if there are any doubts.
In any case you need to take the latest version and to check it when you are
finally going to commit your changes.
Thanks,
Vladimir.
---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing
the minimum to support Java 5 classfiles)
Posted by Salikh Zakirov <Sa...@Intel.com>.
Mark Hindess wrote:
> Salikh Zakirov wrote:
>> Using the fixed classlib snapshot will remove one factor
>> of uncertainty, and will make the DRLVM behaviour more reproducible.
>
> -1
>
> Doing this will hide issues that appear when changes to classlib breaks
> drlvm. At this stage in the project, I'd rather have such issues be as
> visible as possible. Such breakages should be relatively easy to fix
> and any drlvm developer should be capable of rolling back classlib svn
> until things are fixed if they get impatient.
>
> I don't see how it significantly affects reproducibility since it is
> trivial to check/record the versions of classlib and drlvm svn when an
> error occurs?
I agree that recording revision numbers of both classlib and drlvm will be
sufficient to reproduce the problem.
The hard part is finding the "good" ones when the latest revisions
do not work, in a case when someone wants to work on something different
than fixing the latest breakages.
I think that the reasonable compromise is to have both capabilities in the
build system (build with classlib snapshot or with latest checkout), and
leave it up to contributors to decide which way to use.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing
the minimum to support Java 5 classfiles)
Posted by Salikh Zakirov <Sa...@Intel.com>.
Andrey Chernyshev wrote:
> BTW: drlvm build has a built-in machinery to get the resources from
> Internet. Do you think it may make sense to teach it to get the
> classlib binaries snapshots from the web site? I think
> remote.CLASSLIB.archive variable in win/lnx.properties can be used
> for that purpose, we only need to specify there the binaries location
> instead of source tree url.
>
> One of the issues here is that VM may not always work with the latest
> class libraries, hence hardcoding of the specific classlib snapshot
> URL/version in *.properties may be helpful (in the past SVN revision
> was used for that purpose).
+1
Using the fixed classlib snapshot will remove one factor
of uncertainty, and will make the DRLVM behaviour more reproducible.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing the minimum to support Java 5 classfiles)
Posted by Andrey Chernyshev <a....@gmail.com>.
On 7/4/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Andrey Chernyshev wrote:
> >> 4) Change the drlvm build so that its deploy tree layout has no classlib
> >> files in it. So we can do ...
> >
> > As a first step, I suggest that we make drlvm build completely free
> > from the classlib-related tasks and files, this may help to avoid
> > further confusion.
>
> I don't quite see what you mean. We need to use things from classlib to
> build, like headers.
I have created HARMONY-753 to illustrate what I mean :)
Some of the things, like icu libraries, are copied twice at the moment -
one time along with classlib binaries "bulk copy" (target
"deploy.copy_classlib") and once more with the
make/components/extra/icu4c.xml for example.
I'm just suggesting to remove those tasks which are obsoleted by the fact that
we are now using the complete classlib binaries.
>
> > For example, it doesn't have to copy things like
> > icu, seralizer, xalan e.t.c. - they are already taken from pre-built
> > class libraries.
>
> When you say "taken from pre-built class libraries" do you mean
> "pre-build libraries"?
>
> Yes, we don't have to copy those - we really should organize a top level
> dependency tree. I think I posted a note summarizing where we were last
> week.
>
> > If there are no objections, I'm going to submit a
> > patch which will remove some of that stuff from vm build.
> >
> > As a last step, one would remove the copying of the classlib binaries
> > (e.g. deploy.copy_classlib) after we have a top-level build in place.
>
> I think I know what you mean, but I think that we still want this
> option, so that someone could remain working in the drlvm directory.
> IOW, there's no harm leaving it, and the top level build will just tell
> drlvm to build itself into a canonical tree for copying by the top
> level, and finding classlib is up to the top level builder.
>
> Note to self - we'll need to pass the location of the classlib to the
> drlvm as a parameter with a top-level builder...
I believe CLASSLIB_HOME env. variable can be used for that, right?
One note - it currently used to point to the CLASSLIB root in a source
tree, but may be it makes sense to have it pointing directly to the
classib binaries.
BTW: drlvm build has a built-in machinery to get the resources from
Internet. Do you think it may make sense to teach it to get the
classlib binaries snapshots from the web site? I think
remote.CLASSLIB.archive variable in win/lnx.properties can be used
for that purpose, we only need to specify there the binaries location
instead of source tree url.
One of the issues here is that VM may not always work with the latest
class libraries, hence hardcoding of the specific classlib snapshot
URL/version in *.properties may be helpful (in the past SVN revision
was used for that purpose).
Thanks,
Andrey.
>
> geir
>
>
> >
> > Thanks,
> > Andrey.
> >
> >
> > On 6/23/06, Mark Hindess <ma...@googlemail.com> wrote:
> >>
> >> On 23 June 2006 at 17:10, Tim Ellison <t....@gmail.com> wrote:
> >> > Rana Dasgupta wrote:
> >> > > On 6/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >> > >> >>Pavel Pervov wrote:
> >> > >> >> Geir,
> >> > >> >>
> >> > >> >> What's the first thing we do?
> >> > >> >> I'd suggest switching the build to 1.5.
> >> > >> >>
> >> > >> >> The rest will come shortly :)
> >> > >>
> >> > >> >Now that's a plan! :)
> >> > >
> >> > >
> >> > > Hi Geir,
> >> > > Actually what Pavel says makes sense. Not sure what plan we need.
> >> We could
> >> > > do it either way. We can make some changes to the class structure,
> >> loader,
> >> > > and the jit/interpreter, and submit a couple of patches. It is not
> >> the
> >> > > "huge" patch that you have mentioned .. 7-8 files or so. Or we can
> >> switch
> >> > > the build first. This will break drlvm for a short time, and we can
> >> > > submit a
> >> > > couple of bug fixes to get it going again. This way, we will just
> >> add the
> >> > > minimum needed for removing the compiler hack. Whatever way you
> >> think makes
> >> > > sense.
> >> > > However, you started this thread with saying "no patch over the
> >> wall"
> >> > > and making this "learning exercise about DRLVM". Where are you
> >> going with
> >> > > this? Do you want to actually enumerate/discuss which source files
> >> need to
> >> > > change and in what way, on this thread so that more people can
> >> participate?
> >> > >
> >> > > Marginally confused :-)
> >> > > Rana
> >> >
> >> > Just for the record, my goal was to avoid 'moving the goalposts' for
> >> > drlvm to integrate with the classlib and run the tests, apps, etc.
> >> >
> >> > If consensus here is that moving to 5.0 (and thereby delaying that
> >> goal)
> >> > is more desirable then I'm happy to go along with it, though I'm
> >> keen to
> >> > get the entire end-to-end story working soonest.
> >> >
> >> > Regards,
> >> > Tim
> >>
> >> My feeling at the moment is that although drlvm and classlib are working
> >> together[0], it is evident[1] that things are not really integrated.
> >> I would prefer to see "real integration" before we break[0] things by
> >> moving to 5.0.
> >>
> >> As Geir pointed out recently, we are not just a Class library project,
> >> so perhaps a change of focus is warranted? Perhaps if we can agree a
> >> set of prerequisite goals (involving our JVMs) for moving to 5.0, we can
> >> ... err ... encourage this change of focus?
> >>
> >> My prerequisite goals would include things like:
> >>
> >> 1) Fix the (reasonable) 'hacks' that help us get this far with drlvm
> >> integration - e.g. the static libhyprt.a for instance.[2]
> >>
> >> 2) Implement enough of the classlibadapter kernel classes such that
> >> JCHEVM will run 'ant rebuild' in classlib[3]. We have some difficult
> >> problems (thread attach) but there is also a lot of low hanging fruit in
> >> terms of missing or incomplete methods.
> >>
> >> 3) Get drlvm loading with the Harmony launcher from Classlib so we
> >> can have both drlvm and IBM VME around for testing. I think this is
> >> important because it will make it easier for people to test with either
> >> JVM.
> >>
> >> 4) Change the drlvm build so that its deploy tree layout has no classlib
> >> files in it. So we can do ...
> >>
> >> 5) Create the top-level build that can combine the trimmed drlvm deploy
> >> tree and the classlib deploy tree to produce a working jdk. (In much
> >> the same way that we currently combine the classlib and IBM VME.)
> >>
> >> 6) Pull out shared dependencies to top-level so we only need one copy.
> >>
> >>
> >> At the moment, I think moving to 5.0 would increase the divide between
> >> the JVMs and Classlib.
> >>
> >> In the meantime there is still plenty of work to do for those that, for
> >> whatever reasons, don't find these tasks exciting enough - for instance,
> >> the missing java.lang.Character/java.lang.Math methods[4].
> >>
> >> Regards,
> >> Mark.
> >>
> >> [0] Thanks Geir!
> >>
> >> [1] http://issues.apache.org/jira/browse/HARMONY-651
> >>
> >> [2] This isn't a criticism; I think these hacks can be justified.
> >>
> >> [3] I tried this the other day. It got to the second (non-comment) line
> >> of the first ant script before crashing because
> >> ClassLoader.getResources()
> >> isn't implemented yet.
> >>
> >> [4]
> >> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_lang
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing
the minimum to support Java 5 classfiles)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Andrey Chernyshev wrote:
>> 4) Change the drlvm build so that its deploy tree layout has no classlib
>> files in it. So we can do ...
>
> As a first step, I suggest that we make drlvm build completely free
> from the classlib-related tasks and files, this may help to avoid
> further confusion.
I don't quite see what you mean. We need to use things from classlib to
build, like headers.
> For example, it doesn't have to copy things like
> icu, seralizer, xalan e.t.c. - they are already taken from pre-built
> class libraries.
When you say "taken from pre-built class libraries" do you mean
"pre-build libraries"?
Yes, we don't have to copy those - we really should organize a top level
dependency tree. I think I posted a note summarizing where we were last
week.
> If there are no objections, I'm going to submit a
> patch which will remove some of that stuff from vm build.
>
> As a last step, one would remove the copying of the classlib binaries
> (e.g. deploy.copy_classlib) after we have a top-level build in place.
I think I know what you mean, but I think that we still want this
option, so that someone could remain working in the drlvm directory.
IOW, there's no harm leaving it, and the top level build will just tell
drlvm to build itself into a canonical tree for copying by the top
level, and finding classlib is up to the top level builder.
Note to self - we'll need to pass the location of the classlib to the
drlvm as a parameter with a top-level builder...
geir
>
> Thanks,
> Andrey.
>
>
> On 6/23/06, Mark Hindess <ma...@googlemail.com> wrote:
>>
>> On 23 June 2006 at 17:10, Tim Ellison <t....@gmail.com> wrote:
>> > Rana Dasgupta wrote:
>> > > On 6/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> > >> >>Pavel Pervov wrote:
>> > >> >> Geir,
>> > >> >>
>> > >> >> What's the first thing we do?
>> > >> >> I'd suggest switching the build to 1.5.
>> > >> >>
>> > >> >> The rest will come shortly :)
>> > >>
>> > >> >Now that's a plan! :)
>> > >
>> > >
>> > > Hi Geir,
>> > > Actually what Pavel says makes sense. Not sure what plan we need.
>> We could
>> > > do it either way. We can make some changes to the class structure,
>> loader,
>> > > and the jit/interpreter, and submit a couple of patches. It is not
>> the
>> > > "huge" patch that you have mentioned .. 7-8 files or so. Or we can
>> switch
>> > > the build first. This will break drlvm for a short time, and we can
>> > > submit a
>> > > couple of bug fixes to get it going again. This way, we will just
>> add the
>> > > minimum needed for removing the compiler hack. Whatever way you
>> think makes
>> > > sense.
>> > > However, you started this thread with saying "no patch over the
>> wall"
>> > > and making this "learning exercise about DRLVM". Where are you
>> going with
>> > > this? Do you want to actually enumerate/discuss which source files
>> need to
>> > > change and in what way, on this thread so that more people can
>> participate?
>> > >
>> > > Marginally confused :-)
>> > > Rana
>> >
>> > Just for the record, my goal was to avoid 'moving the goalposts' for
>> > drlvm to integrate with the classlib and run the tests, apps, etc.
>> >
>> > If consensus here is that moving to 5.0 (and thereby delaying that
>> goal)
>> > is more desirable then I'm happy to go along with it, though I'm
>> keen to
>> > get the entire end-to-end story working soonest.
>> >
>> > Regards,
>> > Tim
>>
>> My feeling at the moment is that although drlvm and classlib are working
>> together[0], it is evident[1] that things are not really integrated.
>> I would prefer to see "real integration" before we break[0] things by
>> moving to 5.0.
>>
>> As Geir pointed out recently, we are not just a Class library project,
>> so perhaps a change of focus is warranted? Perhaps if we can agree a
>> set of prerequisite goals (involving our JVMs) for moving to 5.0, we can
>> ... err ... encourage this change of focus?
>>
>> My prerequisite goals would include things like:
>>
>> 1) Fix the (reasonable) 'hacks' that help us get this far with drlvm
>> integration - e.g. the static libhyprt.a for instance.[2]
>>
>> 2) Implement enough of the classlibadapter kernel classes such that
>> JCHEVM will run 'ant rebuild' in classlib[3]. We have some difficult
>> problems (thread attach) but there is also a lot of low hanging fruit in
>> terms of missing or incomplete methods.
>>
>> 3) Get drlvm loading with the Harmony launcher from Classlib so we
>> can have both drlvm and IBM VME around for testing. I think this is
>> important because it will make it easier for people to test with either
>> JVM.
>>
>> 4) Change the drlvm build so that its deploy tree layout has no classlib
>> files in it. So we can do ...
>>
>> 5) Create the top-level build that can combine the trimmed drlvm deploy
>> tree and the classlib deploy tree to produce a working jdk. (In much
>> the same way that we currently combine the classlib and IBM VME.)
>>
>> 6) Pull out shared dependencies to top-level so we only need one copy.
>>
>>
>> At the moment, I think moving to 5.0 would increase the divide between
>> the JVMs and Classlib.
>>
>> In the meantime there is still plenty of work to do for those that, for
>> whatever reasons, don't find these tasks exciting enough - for instance,
>> the missing java.lang.Character/java.lang.Math methods[4].
>>
>> Regards,
>> Mark.
>>
>> [0] Thanks Geir!
>>
>> [1] http://issues.apache.org/jira/browse/HARMONY-651
>>
>> [2] This isn't a criticism; I think these hacks can be justified.
>>
>> [3] I tried this the other day. It got to the second (non-comment) line
>> of the first ant script before crashing because
>> ClassLoader.getResources()
>> isn't implemented yet.
>>
>> [4]
>> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_lang
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org