harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [drlvm] Removing classlib-related tasks from VM build (was Doing the minimum to support Java 5 classfiles)
Date Thu, 06 Jul 2006 14:39:45 GMT


Andrey Chernyshev wrote:
> On 7/4/06, Geir Magnusson Jr <geir@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 <mark.hindess@googlemail.com> wrote:
>> >>
>> >> On 23 June 2006 at 17:10, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> >> > Rana Dasgupta wrote:
>> >> > > On 6/23/06, Geir Magnusson Jr <geir@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


Mime
View raw message