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] DRLVM, jre/bin/default and launcher
Date Fri, 08 Sep 2006 11:56:14 GMT


Evgueni Brevnov wrote:
> On 9/7/06, Geir Magnusson Jr. <geir@pobox.com> 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?

> 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. <geir@pobox.com> 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. <geir@pobox.com>
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:
>> >> >>>> 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
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>>
>> >> 
>> ------------------------------------------------------------------------
>> >> >>>>
>> >> >>>> >
>> >> >>>> >
>> >> ---------------------------------------------------------------------
>> >> >>>> > 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
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>> 
>> ---------------------------------------------------------------------
>> >> >>> 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
>> >> >>
>> >> >
>> >> > 
>> ---------------------------------------------------------------------
>> >> > 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
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
> 
> ---------------------------------------------------------------------
> 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