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] Doing the minimum to support Java 5 classfiles
Date Mon, 26 Jun 2006 19:56:58 GMT


Andrey Chernyshev wrote:
> 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.
> 
> I agree the integration doesn't look perfect. On the other hand,
> improving integration and moving to 5.0 could be quite independent.
> Integration issues seem to be mostly related to the building /
> packaging, while 5.0 support would require adding / changing a code.

This is my POV as well.  I'm guessing they are independent, at least the
basics for accepting a v5 classfile.

> 
>>
>> 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]
> 
> It seems libhyprt is needed by VMI module to implement GetPortLibrary
> function.
> I guess static hyprt library is still needed for Windows (this is why
> it was added) while it isn't needed on Linux. The dependency on hyprt
> could be handled more gracefully with <select os="XXX"> tags.

I don't understand why it has to be static.

> 
>>
>> 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.
> 
> Do we want every VM, capable of working with Harmony classlib, be
> started with the Harmony launcher? 

No, but ours certainly could.

> It's probably could be too
> restrictive and may require additional work for adopting other VM's
> for classlib.
> However, I completely agree that the non-standard name breaks other
> tools and scripts. Wouldn't it be sufficient just to rename ij->java?

Yes

> 
>>
>> 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.
> 
> It looks like most of these issues are relating to the building files.
> Geir, would you be willing to work on that, or, someone else could try?

Anyone can try.  I have a top-level federation started, and will do more
tomorrow and get that checked in.

What would help is to rip out all the dependency stuff for DRLVM and
just move to a peer directory to DRLVM - the key will be letting us set
'pointers' via properties in the DRLVM build.

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


Mime
View raw message