harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm] DRLVM, jre/bin/default and launcher
Date Fri, 08 Sep 2006 10:02:51 GMT
On 9/7/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
>
> Evgueni Brevnov wrote:
> > On 9/7/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >> Code is checked in for linux - and updating and testing now on WinXP.
> >>
> >> The issue was that all of our library loading was done with full paths,
> >> which didn't let APR via dlopen() use LD_LIBRARY_PATH.
> >>
> >> So I made some small mods - please review.  One problem I found was that
> >>  I had to make assumptions such as passing NULL instead of a path being
> >> safe, because there was no comments in the code about expected inputs
> >> (or resulting outputs).
> >>
> >> I also neutered "vm.boot.library.path" to be "" unless set on command
> >> line, rather than be the directory of the launching executable, as I
> >> figured that a) I needed to have it be "" and b) that would lead to some
> >> interesting failures when people tried to embed DRLVM in other apps or
> >> such.
> >
> > 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. 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


Mime
View raw message