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 Tue, 04 Jul 2006 16:52:18 GMT


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 <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


Mime
View raw message