Andrey, Angela, If I understood a problem correctly Alexey asked to make a developer's life easier. It looks like now a developer should rebuild class library, then to rebuild DRLVM each time he wants to check his class library changes with DRLVM.
Can we simplify the procedure? For example, if I don't change DRLVM, I shouldn't rebuild it each time to have correct files in jre/bin. * This is more conventional. * This allows people to use prebuilt DRLVM binaries. * Prebuilt binaries minimize astonishment for a class library developer. Alexey mentioned scripts as a quick solution. Is it possible to solve this problem on a build script level? Or should we change a launcher to reorder paths in LD_LIBRARY_PATH? Your design discussion about long term solution is quite interesting reading as well. Andrey said IBM should expose object layout. Let me speculate on it a bit. I really don't have any knowledge on J9, so any coincidence is not intentional. * Imagine that J9 is able to work with Sun's class library that was licensed by IBM from Sun for 10 years. * Imagine that class library has functions which access objects directly for performance reasons. Taking these two statements together I don't think we should count on exposing this object layout to the third party when this third party is a competing Open Source community. Thank you, Alexei On 11/13/06, Angela Lin <[EMAIL PROTECTED]> wrote:
Hmm... Pre-Harmony, the IBM VM + classlib used the same thread library. When the classlib was contributed, I guess they forked the thread lib and changed the names of the functions. (I'm only speculating since I wasn't involved in that process.) hythr should be virtually identical to a subset of j9thr23.dll. I agree, the IBM VM + classlib should be using the same thread library. It shouldn't be hard to implement a redirector lib from hythr to j9thr. Would this obsolete the current classlib hythr implementation? Angela On 11/13/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote: > On 11/13/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote: > > Guys, > > > > is there any progress in making possible for IBM and DRL VM to use the > > same hythr library? > > I imagine they would have to share some more VM internals first, like > GC or object layout interface, before they can migrate to a common > threading library :) > > > > > It is really a pain now to run class library tests on DRLVM now. And > > nearly impossible to easy switch VMs by launcher command line > > parameters. Since class library builds IBM version of hythr library > > and rewrites it in jre/bin directory. So you need to copy this library > > What if just disable copying of the hythr.dll into the > deploy/jre/jdk/bin directory, > may be harmony-vme could be providing the one? > > > from DRL VM after each build. (Yes, I know how to write scripts :) > > > > If it is not possible for both VMs to use the same library probably we > > need to move these libraries to VM directories... > > +1. > Seems like we don't have any VM at the moment which would be really > using the hythr from classlib. Even IBM VME doesn't use the hythr. As > Tim wrote earlier, VME is using it's own threading library called > j9thr23 [1]. Does it differ a much from the hythr? > > Guess it might be favourable for the classlib + IBM VME stack as well > if it was using a single thread library. Would it be possible for VME > to include a straightforward hythr implementation which can delegate > hythread_* calls to the j9thr23? > > Thanks, > Andrey. > > > [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED] > > > > > > SY, Alexey > > > > > -- > Andrey Chernyshev > Intel Enterprise Solutions Software Division >
-- Thank you, Alexei
