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 Thu, 07 Sep 2006 07:23:05 GMT
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'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).

>
> 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


Mime
View raw message