Andrey Chernyshev wrote: > On 6/23/06, Mark Hindess <[EMAIL PROTECTED]> wrote: >> >> On 23 June 2006 at 17:10, Tim Ellison <[EMAIL PROTECTED]> wrote: >> > Rana Dasgupta wrote: >> > > On 6/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
