On 9/8/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Evgueni Brevnov wrote: > On 9/7/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> Evgueni Brevnov wrote: >> > >> > It seems we don't need vm.boot.library.path anymore. I propose to >> > remove it from the sources completely. What do you think? >> > >> >> I wasn't sure. It is used in Classloader and Runtime, I suppose as a >> parallel to Sun's equivalent? >> > No, not as Sun's equivalent. There are two different strategies to > load VM libraries. The first one which was implemented in DRLVM before > assumes full VM responsibility to load its dlls. It was done by means > of vm.boot.library.path option. Search order is also important. DRLVM > searches libraries in the following order java.library.path then > system path then vm.boot.library.path. Probably, it is wrong sequence > or it doesn't matter at all but it seems reference implementation does > it exactly the same way. Does the RI have a "vm.boot.library.path" option?
Yes, it has I don't remeber exact name.
> The second one which we are implementing now > is to let launcher to specify the search order. Actually, not only the > launcher but any native application which uses Invocation API. It > seems for me to be a little strict requirement. At least spec doesn't > require it. So it seems the first approach is more consistent with the > spec. But the second one gives as flexibility to place VM under any > directory. So....what to choose? > > >> >> >> >> I'll see what I can take out of HARMONY-1390 for some of the issues >> >> related to teardown. Or, Evgueni, you can tell me to close it and we >> >> can do another one. There seemed to be a few extra things included in >> >> that patch, btw :) >> > Ok, let me give you some details regarding HARMONY-1390 patches. You >> > definitely don't need classlib.launcher.patch anymore. >> > drlvm.launcghr.patch contains the following logic parts: >> > 1) Get rid of old DRLVM launcher and related stuff like parsing >> > command line (new launcher do it for us) and executing main method. >> > BTW I just noticed that I forgot to delete useless code in >> > j.l.VMStarter class. >> > 2) Fix stack trace creation for new scheme. Now when main thread >> > starts application main method from native code through JNI we have >> > different few first frames on the stack. See changes for >> > vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp >> > 3) Fix -help and -X options processing when VM is created by calling >> > JNI_CreateJavaVM. >> > 4) Changes related to new location of VM's dll's. >> > >> > We don't need part number 4) anymore since you did it in more elegant >> > way. I believe it still makes sense to apply parts 1) 2) 3). >> >> I was definitely going to do 1) and 3). I didn't really yet understand >> 2), but I'll study that and ask any questions if I have any. >> >> Thanks >> >> geir >> >> > >> >> >> >> Tomorrow, I'll finish the changes to the build so we get a >> >> launcher-based JRE and HDK. >> >> >> >> I know this isn't perfect, but it's a step forward - thanks all for >> all >> >> the help. >> >> >> >> geir >> >> >> >> (and for the record, working in C, C++ and Java all at the same >> time is >> >> a hoot...) >> >> >> >> >> >> Geir Magnusson Jr. wrote: >> >> > Ok, I think I have this working now. >> >> > >> >> > DRLVM can be put anywhere and it works w/ the launcher w/o any >> >> unnatural >> >> > acts with command line parameters and/or scripts. >> >> > >> >> > There are a few things to chat about - I'll get my thoughts together >> >> > later tonight and post, and check in the code. I just wanted to let >> >> > people know if they were thinking about working on it. >> >> > >> >> > geir >> >> > >> >> > >> >> > >> >> > Geir Magnusson Jr. wrote: >> >> >> >> >> >> >> >> >> Evgueni Brevnov wrote: >> >> >>> On 9/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >>>> >> >> >>>> >> >> >>>> Evgueni Brevnov wrote: >> >> >>>> > HI All, >> >> >>>> > >> >> >>>> > Good news! I have a patch to run DRLVM with the classlib's >> >> launcher >> >> >>>> > (I've checked Hello and Eclipse applications on Windows only). >> >> >>>> > Actually, there are two patches. The first one is for classlib >> >> which >> >> >>>> > changes vm default directory to drlvm. >> >> >>>> >> >> >>>> I don't think we should do that - we'll keep it the same as it is >> >> now - >> >> >>>> "default". >> >> >>>> >> >> >>>> Why should we change it? >> >> >>> >> >> >>> I don't care about it too much. Let it be "default". In that case >> >> >>> -vmdir option should be specified each time. Is it convenient for >> >> >>> users? >> >> >> >> >> >> ? right now, "default" is the default. So the user doesn't >> have to >> >> >> specify anything... >> >> >> >> >> >> With the DRLVM stuff in jre/bin/default the user just types >> >> >> >> >> >> java >> >> >> >> >> >> >> >> >> > BTW it seems there will be some problems with hythr.dll library >> >> >>> if we wish to use drlvm and j9 in simultaneously. But that's >> another >> >> >>> story... >> >> >> >> >> >> Yes, we need to resolve this. >> >> >> >> >> >>> >> >> >>>> >> >> >>>> > The second one is for build >> >> >>>> > system and VM itself. Unfortunatelly, it is impossible to >> >> eliminate >> >> >>>> > all problems in a short period of time. There is still a >> bunch of >> >> >>>> work >> >> >>>> > in initialization and jni modules. So this patch is just a one >> >> more >> >> >>>> > step to our goal. >> >> >>>> >> >> >>>> Great. As I said in other mails, the build stuff isn't the >> part to >> >> >>>> worry about but rather the VM itself. >> >> >>>> >> >> >>>> So does this patch do it completely, or should we wait? >> >> >>> >> >> >>> Yes, the patch contains changes for both parts vm and build. >> >> >>> It was easy for me to change the build than do manual >> manipulations >> >> >>> each time to >> >> >>> check whether it runs OK or not. >> >> >> >> >> >> So does this mean if I apply the patch, then DRLVM works w/ the >> >> >> launcher from the jre/bin/default directory w/o any problems? >> >> >> >> >> >> geir >> >> >> >> >> >>> >> >> >>>> >> >> >>>> > >> >> >>>> > The vm patch is quite heavy so I attach it and classlib patch. >> >> >>>> > Hope it will work not only for me :-) >> >> >>>> > >> >> >>>> > >> >> >>>> > On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> Salikh Zakirov wrote: >> >> >>>> >> > Andrey Chernyshev wrote: >> >> >>>> >> >> 1. Fix the DRLVM layout - rename vmcore to "harmonyvm" and >> >> move >> >> >>>> >> >> ..dll/.so into the "default" subdirectory such that one >> >> doesn't >> >> >>>> >> have to >> >> >>>> >> >> type -vm and -vmdir options; >> >> >>>> >> > >> >> >>>> >> > While would you want to rename DRLVM to Harmony VM? >> >> >>>> >> > It feels to me like claiming DRLVM to be "the only" >> Harmony VM. >> >> >>>> >> > On the contrary, I thought Harmony project is about >> >> *encouraging* >> >> >>>> >> diversity. >> >> >>>> >> > >> >> >>>> >> > I think having library named libdrlvm.so would be much >> better. >> >> >>>> >> >> >> >>>> >> No - the launcher picks up the vm from "harmonyvm.dll" (or >> >> .so) so >> >> >>>> >> that's what we'll name it. >> >> >>>> >> >> >> >>>> >> Then it makes it easy. put J9 in jre/bin/j9 and drlvm in >> >> >>>> jre/bin/drlvm >> >> >>>> >> and then >> >> >>>> >> >> >> >>>> >> java -vmdir:j9 >> >> >>>> >> >> >> >>>> >> or >> >> >>>> >> >> >> >>>> >> java -vmdir:drlvm >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> etc >> >> >>>> >> >> >> >>>> >> geir >> >> >>>> >> >> >> >>>> >> > >> >> >>>> >> >> 2. Exclude building of the "original" launcher from the >> DRLVM >> >> >>>> build - >> >> >>>> >> >> it currently conflicts with the classlib launcher (both are >> >> >>>> called >> >> >>>> >> >> "java"). >> >> >>>> >> >> >> >> >>>> >> >> 3. Aside from the hythread, it may also have a sense to >> >> make the >> >> >>>> >> >> classlib and DRLVM using the same zlib dll/so >> (preferably the >> >> >>>> system >> >> >>>> >> >> one). >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> >> > >> >> >>>> >> >> --------------------------------------------------------------------- >> >> >>>> >> > Terms of use : >> http://incubator.apache.org/harmony/mailing.html >> >> >>>> >> > To unsubscribe, e-mail: >> >> >>>> [EMAIL PROTECTED] >> >> >>>> >> > For additional commands, e-mail: >> >> >>>> [EMAIL PROTECTED] >> >> >>>> >> > >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> --------------------------------------------------------------------- >> >> >>>> >> Terms of use : >> http://incubator.apache.org/harmony/mailing.html >> >> >>>> >> To unsubscribe, e-mail: >> >> [EMAIL PROTECTED] >> >> >>>> >> For additional commands, e-mail: >> >> >>>> [EMAIL PROTECTED] >> >> >>>> >> >> >> >>>> >> >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> >> >> >> ------------------------------------------------------------------------ >> >> >>>> >> >> >>>> > >> >> >>>> > >> >> --------------------------------------------------------------------- >> >> >>>> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> >>>> > To unsubscribe, e-mail: >> >> [EMAIL PROTECTED] >> >> >>>> > For additional commands, e-mail: >> >> >>>> [EMAIL PROTECTED] >> >> >>>> >> >> >>>> >> >> --------------------------------------------------------------------- >> >> >>>> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> >>>> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> >> >>>> For additional commands, e-mail: >> >> [EMAIL PROTECTED] >> >> >>>> >> >> >>>> >> >> >>> >> >> >>> >> --------------------------------------------------------------------- >> >> >>> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> >>> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> >> >>> For additional commands, e-mail: >> >> [EMAIL PROTECTED] >> >> >>> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> >> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> >> >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> >> >> >> >> > >> >> > >> --------------------------------------------------------------------- >> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: >> [EMAIL PROTECTED] >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
