You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2006/08/31 14:13:10 UTC
[drlvm] DRLVM, jre/bin/default and launcher
We need to make DRLVM work with the launcher in the same way that J9
works with the launcher. It's a royal PITA to do an ant-clean and have
DRLVM wiped out of the deploy/jdk/jre directory in classlib-land.
My goal here is two fold -
a) make it easy for people to have both DRLVM and j9 around for A/B testing
b) make DRLVM the default VM we use for everything
I know that we still have the epic argument around hythread to resolve,
but we can do this task first.
Does anyone want to volunteer to take this on? If not, I'll do it, but
I know that there are people out there that know DRLVM far better than I
do...
geir
---------------------------------------------------------------------
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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Andrey Chernyshev wrote:
> On 9/1/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>> Hi Geir,
>>
>> I'm very enthusiastic about making DRLVM to work with the launcher. It
>> requires implementation of the Invocation API to a certain extent. For
>> example it's enougth to have only partial support for
>
> To some extent, some of those invocation API you mentioned have been
> already implemented. I believe DRLVM can already be started with the
> launcher if type a command:
>
> java -vm:vmcore -vmdir:.
Yes. But it won't work if vmdir isn't "."
>
> If we want to complete the transition to the classlib's launcher, then
> I guess we need to do the following:
>
> 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;
Yes, but that can be done in the build script.
The problem is that DRLVM - apparently EM which seems to a bit of the
loading - can't seem to handle when resources aren't in "."
>
> 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).
Yep.
But first, we need to fix EM so that resources can be in a subdirectory.
so to summarize :
I don't believe the issue is as simple as a build script. I thought I
experimented with getting DRLVM to work with the normal launcher when
DRLVM was in /default. If memory serves, it doesnt' work.
geir
>
>
> Thanks,
> Andrey.
>
>
>> DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is
>> necessary as well. So if there is no objections I can start working on
>> it right now.
>>
>> Thanks
>> Evgueni.
>>
>> On 8/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > We need to make DRLVM work with the launcher in the same way that J9
>> > works with the launcher. It's a royal PITA to do an ant-clean and have
>> > DRLVM wiped out of the deploy/jdk/jre directory in classlib-land.
>> >
>> > My goal here is two fold -
>> >
>> > a) make it easy for people to have both DRLVM and j9 around for A/B
>> testing
>> >
>> > b) make DRLVM the default VM we use for everything
>> >
>> > I know that we still have the epic argument around hythread to resolve,
>> > but we can do this task first.
>> >
>> > Does anyone want to volunteer to take this on? If not, I'll do it, but
>> > I know that there are people out there that know DRLVM far better
>> than I
>> > do...
>> >
>> > geir
>> >
>> > ---------------------------------------------------------------------
>> > 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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Alexey Varlamov <al...@gmail.com>.
2006/9/6, Evgueni Brevnov <ev...@gmail.com>:
> On 9/6/06, Geir Magnusson Jr. <ge...@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? 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...
Evgueni,
The patch you provided hardcodes name of vmdir, so the command-line
option would not help... OTOH, indeed it is possible to put J9 in
jre/bin/j9 and drlvm in jre/bin/drlvm (exactly as Geir said) and just
symlink one of them to jre/bin/default as needed :)
Regarding hythr lib, DRLVM can load the lib from it's own directory,
isn't it? BTW, is there any reason to name it equally with the
classlib's counterpart? I suppose it is loaded only dynamically
anyway.
Still I think this patch is enough for basic launcher support; we can
make it more reliable and customizable later.
--
Alexey
> >
> > > 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.
>
> >
> > >
> > > 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. <ge...@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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Gregory Shimansky <gs...@gmail.com>.
On Friday 08 September 2006 17:31 Evgueni Brevnov wrote:
> On 9/8/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > Evgueni Brevnov wrote:
> > > On 9/7/06, Geir Magnusson Jr. <ge...@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?
>
> Yes, it has I don't remeber exact name.
It is sun.boot.library.path.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 9/8/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> Evgueni Brevnov wrote:
> > On 9/7/06, Geir Magnusson Jr. <ge...@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?
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. <ge...@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. <ge...@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
>
>
---------------------------------------------------------------------
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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Evgueni Brevnov wrote:
> On 9/7/06, Geir Magnusson Jr. <ge...@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. <ge...@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. <ge...@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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 9/7/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> Evgueni Brevnov wrote:
> > On 9/7/06, Geir Magnusson Jr. <ge...@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. <ge...@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. <ge...@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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Evgueni Brevnov wrote:
> On 9/7/06, Geir Magnusson Jr. <ge...@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?
>>
>> 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. <ge...@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. <ge...@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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 9/7/06, Geir Magnusson Jr. <ge...@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. <ge...@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. <ge...@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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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.
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 :)
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. <ge...@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. <ge...@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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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. <ge...@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. <ge...@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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Evgueni Brevnov wrote:
> On 9/6/06, Geir Magnusson Jr. <ge...@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. <ge...@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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 9/6/06, Geir Magnusson Jr. <ge...@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? 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...
>
> > 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.
>
> >
> > 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. <ge...@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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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?
> 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?
>
> 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. <ge...@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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Thanks - putting patches in JIRA is the best way.
geir
Evgueni Brevnov wrote:
> Hi Geir,
>
> It seems not all of us are able to see my attachments :-(
> I've created new jira HARMONY-1390 with attachments.
>
> Thanks
> Evgueni.
>
> On 9/6/06, Evgueni Brevnov <ev...@gmail.com> 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. 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.
>>
>> 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. <ge...@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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Evgueni Brevnov <ev...@gmail.com>.
Hi Geir,
It seems not all of us are able to see my attachments :-(
I've created new jira HARMONY-1390 with attachments.
Thanks
Evgueni.
On 9/6/06, Evgueni Brevnov <ev...@gmail.com> 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. 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.
>
> 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. <ge...@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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Evgueni Brevnov <ev...@gmail.com>.
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. 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.
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. <ge...@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
>
>
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 10/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> Vladimir Ivanov wrote:
> > As we know the current IBM VM does not support all 'standard' java
> options.
> >
> > IBM VM peoples, could you give some expectation when this support will
> be
> > available (1 month, 3 or 6 ...)?
>
> Why do we as the Harmony project care?
Now we have 2 VM at Harmony and to check API behavior I use both of them. It
will be more comfortable for me to have one arguments set for both VMs.
So, I think about my conveniences only :)
Thanks, Vladimir
geir
>
> >
> > thanks, Vladimir
> >
> >
> >
> > The standard options from my point of view are (without deprecated):
> > tmp>java
> > Usage: java [-options] class [args...]
> > (to execute a class)
> > or java [-options] -jar jarfile [args...]
> > (to execute a jar file)
> >
> > where options include:
> > -client to select the "client" VM
> > -server to select the "server" VM
> > -hotspot is a synonym for the "client" VM [deprecated]
> > The default VM is client.
> >
> > -cp <class search path of directories and zip/jar files>
> > -classpath <class search path of directories and zip/jar files>
> > A ; separated list of directories, JAR archives,
> > and ZIP archives to search for class files.
> > -D<name>=<value>
> > set a system property
> > -verbose[:class|gc|jni]
> > enable verbose output
> > -version print product version and exit
> > -version:<value>
> > require the specified version to run
> > -showversion print product version and continue
> > -jre-restrict-search | -jre-no-restrict-search
> > include/exclude user private JREs in the version search
> > -? -help print this help message
> > -X print help on non-standard options
> > -ea[:<packagename>...|:<classname>]
> > -enableassertions[:<packagename>...|:<classname>]
> > enable assertions
> > -da[:<packagename>...|:<classname>]
> > -disableassertions[:<packagename>...|:<classname>]
> > disable assertions
> > -esa | -enablesystemassertions
> > enable system assertions
> > -dsa | -disablesystemassertions
> > disable system assertions
> >
> >
> >
> > On 9/4/06, Oliver Deakin <ol...@googlemail.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.
> >> >
> >>
> >> The Harmony launcher looks for harmonyvm.dll as its default vm library.
> >> It's just a generic
> >> name so that the launcher can find the correct library without -vm. The
> >> IBM VME also
> >> contains a harmonyvm.dll, which is why it works without specifying
> >> command line options
> >>
> >> Regards,
> >> Oliver
> >>
> >> >
> >> >> 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
> >> >
> >> >
> >> >
> >>
> >> --
> >> Oliver Deakin
> >> IBM United Kingdom Limited
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Vladimir Ivanov wrote:
> As we know the current IBM VM does not support all 'standard' java options.
>
> IBM VM peoples, could you give some expectation when this support will be
> available (1 month, 3 or 6 ...)?
Why do we as the Harmony project care?
geir
>
> thanks, Vladimir
>
>
>
> The standard options from my point of view are (without deprecated):
> tmp>java
> Usage: java [-options] class [args...]
> (to execute a class)
> or java [-options] -jar jarfile [args...]
> (to execute a jar file)
>
> where options include:
> -client to select the "client" VM
> -server to select the "server" VM
> -hotspot is a synonym for the "client" VM [deprecated]
> The default VM is client.
>
> -cp <class search path of directories and zip/jar files>
> -classpath <class search path of directories and zip/jar files>
> A ; separated list of directories, JAR archives,
> and ZIP archives to search for class files.
> -D<name>=<value>
> set a system property
> -verbose[:class|gc|jni]
> enable verbose output
> -version print product version and exit
> -version:<value>
> require the specified version to run
> -showversion print product version and continue
> -jre-restrict-search | -jre-no-restrict-search
> include/exclude user private JREs in the version search
> -? -help print this help message
> -X print help on non-standard options
> -ea[:<packagename>...|:<classname>]
> -enableassertions[:<packagename>...|:<classname>]
> enable assertions
> -da[:<packagename>...|:<classname>]
> -disableassertions[:<packagename>...|:<classname>]
> disable assertions
> -esa | -enablesystemassertions
> enable system assertions
> -dsa | -disablesystemassertions
> disable system assertions
>
>
>
> On 9/4/06, Oliver Deakin <ol...@googlemail.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.
>> >
>>
>> The Harmony launcher looks for harmonyvm.dll as its default vm library.
>> It's just a generic
>> name so that the launcher can find the correct library without -vm. The
>> IBM VME also
>> contains a harmonyvm.dll, which is why it works without specifying
>> command line options
>>
>> Regards,
>> Oliver
>>
>> >
>> >> 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
>> >
>> >
>> >
>>
>> --
>> Oliver Deakin
>> IBM United Kingdom Limited
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 10/4/06, Ivan Popov <iv...@gmail.com> wrote:
>
> J2SE documentation explicitely mention standard and non-standard but
> well-known option for 'java' tool in [1] and [2]. I think it makes
> sense to follow this description rather than help message, they are
> not equal.
>From my point of view we should support all widely used options and it
should not depend on standard/non-standard definition (for example, support
of '-Xmx' option is useful too).
Seems, it should be discussed and store somewhere.
Thanks, Vladimir
[1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html
> [2] http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html
>
> Ivan.
>
> On 10/4/06, Vladimir Ivanov <iv...@gmail.com> wrote:
> > As we know the current IBM VM does not support all 'standard' java
> options.
> >
> > IBM VM peoples, could you give some expectation when this support will
> be
> > available (1 month, 3 or 6 ...)?
> >
> > thanks, Vladimir
> >
> >
> >
> > The standard options from my point of view are (without deprecated):
> > tmp>java
> > Usage: java [-options] class [args...]
> > (to execute a class)
> > or java [-options] -jar jarfile [args...]
> > (to execute a jar file)
> >
> > where options include:
> > -client to select the "client" VM
> > -server to select the "server" VM
> > -hotspot is a synonym for the "client" VM [deprecated]
> > The default VM is client.
> >
> > -cp <class search path of directories and zip/jar files>
> > -classpath <class search path of directories and zip/jar files>
> > A ; separated list of directories, JAR archives,
> > and ZIP archives to search for class files.
> > -D<name>=<value>
> > set a system property
> > -verbose[:class|gc|jni]
> > enable verbose output
> > -version print product version and exit
> > -version:<value>
> > require the specified version to run
> > -showversion print product version and continue
> > -jre-restrict-search | -jre-no-restrict-search
> > include/exclude user private JREs in the version search
> > -? -help print this help message
> > -X print help on non-standard options
> > -ea[:<packagename>...|:<classname>]
> > -enableassertions[:<packagename>...|:<classname>]
> > enable assertions
> > -da[:<packagename>...|:<classname>]
> > -disableassertions[:<packagename>...|:<classname>]
> > disable assertions
> > -esa | -enablesystemassertions
> > enable system assertions
> > -dsa | -disablesystemassertions
> > disable system assertions
> >
> >
> >
> > On 9/4/06, Oliver Deakin <ol...@googlemail.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.
> > > >
> > >
> > > The Harmony launcher looks for harmonyvm.dll as its default vm
> library.
> > > It's just a generic
> > > name so that the launcher can find the correct library without -vm.
> The
> > > IBM VME also
> > > contains a harmonyvm.dll, which is why it works without specifying
> > > command line options
> > >
> > > Regards,
> > > Oliver
> > >
> > > >
> > > >> 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
> > > >
> > > >
> > > >
> > >
> > > --
> > > Oliver Deakin
> > > IBM United Kingdom Limited
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
>
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Ivan Popov <iv...@gmail.com>.
J2SE documentation explicitely mention standard and non-standard but
well-known option for 'java' tool in [1] and [2]. I think it makes
sense to follow this description rather than help message, they are
not equal.
[1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html
[2] http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html
Ivan.
On 10/4/06, Vladimir Ivanov <iv...@gmail.com> wrote:
> As we know the current IBM VM does not support all 'standard' java options.
>
> IBM VM peoples, could you give some expectation when this support will be
> available (1 month, 3 or 6 ...)?
>
> thanks, Vladimir
>
>
>
> The standard options from my point of view are (without deprecated):
> tmp>java
> Usage: java [-options] class [args...]
> (to execute a class)
> or java [-options] -jar jarfile [args...]
> (to execute a jar file)
>
> where options include:
> -client to select the "client" VM
> -server to select the "server" VM
> -hotspot is a synonym for the "client" VM [deprecated]
> The default VM is client.
>
> -cp <class search path of directories and zip/jar files>
> -classpath <class search path of directories and zip/jar files>
> A ; separated list of directories, JAR archives,
> and ZIP archives to search for class files.
> -D<name>=<value>
> set a system property
> -verbose[:class|gc|jni]
> enable verbose output
> -version print product version and exit
> -version:<value>
> require the specified version to run
> -showversion print product version and continue
> -jre-restrict-search | -jre-no-restrict-search
> include/exclude user private JREs in the version search
> -? -help print this help message
> -X print help on non-standard options
> -ea[:<packagename>...|:<classname>]
> -enableassertions[:<packagename>...|:<classname>]
> enable assertions
> -da[:<packagename>...|:<classname>]
> -disableassertions[:<packagename>...|:<classname>]
> disable assertions
> -esa | -enablesystemassertions
> enable system assertions
> -dsa | -disablesystemassertions
> disable system assertions
>
>
>
> On 9/4/06, Oliver Deakin <ol...@googlemail.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.
> > >
> >
> > The Harmony launcher looks for harmonyvm.dll as its default vm library.
> > It's just a generic
> > name so that the launcher can find the correct library without -vm. The
> > IBM VME also
> > contains a harmonyvm.dll, which is why it works without specifying
> > command line options
> >
> > Regards,
> > Oliver
> >
> > >
> > >> 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
> > >
> > >
> > >
> >
> > --
> > Oliver Deakin
> > IBM United Kingdom Limited
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Vladimir Ivanov <iv...@gmail.com>.
As we know the current IBM VM does not support all 'standard' java options.
IBM VM peoples, could you give some expectation when this support will be
available (1 month, 3 or 6 ...)?
thanks, Vladimir
The standard options from my point of view are (without deprecated):
tmp>java
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)
where options include:
-client to select the "client" VM
-server to select the "server" VM
-hotspot is a synonym for the "client" VM [deprecated]
The default VM is client.
-cp <class search path of directories and zip/jar files>
-classpath <class search path of directories and zip/jar files>
A ; separated list of directories, JAR archives,
and ZIP archives to search for class files.
-D<name>=<value>
set a system property
-verbose[:class|gc|jni]
enable verbose output
-version print product version and exit
-version:<value>
require the specified version to run
-showversion print product version and continue
-jre-restrict-search | -jre-no-restrict-search
include/exclude user private JREs in the version search
-? -help print this help message
-X print help on non-standard options
-ea[:<packagename>...|:<classname>]
-enableassertions[:<packagename>...|:<classname>]
enable assertions
-da[:<packagename>...|:<classname>]
-disableassertions[:<packagename>...|:<classname>]
disable assertions
-esa | -enablesystemassertions
enable system assertions
-dsa | -disablesystemassertions
disable system assertions
On 9/4/06, Oliver Deakin <ol...@googlemail.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.
> >
>
> The Harmony launcher looks for harmonyvm.dll as its default vm library.
> It's just a generic
> name so that the launcher can find the correct library without -vm. The
> IBM VME also
> contains a harmonyvm.dll, which is why it works without specifying
> command line options
>
> Regards,
> Oliver
>
> >
> >> 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
> >
> >
> >
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>
> ---------------------------------------------------------------------
> 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
>
>
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Oliver Deakin <ol...@googlemail.com>.
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.
>
The Harmony launcher looks for harmonyvm.dll as its default vm library.
It's just a generic
name so that the launcher can find the correct library without -vm. The
IBM VME also
contains a harmonyvm.dll, which is why it works without specifying
command line options
Regards,
Oliver
>
>> 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
>
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Salikh Zakirov <Sa...@Intel.com>.
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.
> 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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Andrey Chernyshev <a....@gmail.com>.
On 9/1/06, Evgueni Brevnov <ev...@gmail.com> wrote:
> Hi Geir,
>
> I'm very enthusiastic about making DRLVM to work with the launcher. It
> requires implementation of the Invocation API to a certain extent. For
> example it's enougth to have only partial support for
To some extent, some of those invocation API you mentioned have been
already implemented. I believe DRLVM can already be started with the
launcher if type a command:
java -vm:vmcore -vmdir:.
If we want to complete the transition to the classlib's launcher, then
I guess we need to do the following:
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;
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).
Thanks,
Andrey.
> DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is
> necessary as well. So if there is no objections I can start working on
> it right now.
>
> Thanks
> Evgueni.
>
> On 8/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > We need to make DRLVM work with the launcher in the same way that J9
> > works with the launcher. It's a royal PITA to do an ant-clean and have
> > DRLVM wiped out of the deploy/jdk/jre directory in classlib-land.
> >
> > My goal here is two fold -
> >
> > a) make it easy for people to have both DRLVM and j9 around for A/B testing
> >
> > b) make DRLVM the default VM we use for everything
> >
> > I know that we still have the epic argument around hythread to resolve,
> > but we can do this task first.
> >
> > Does anyone want to volunteer to take this on? If not, I'll do it, but
> > I know that there are people out there that know DRLVM far better than I
> > do...
> >
> > geir
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Cool.
I guess the question is, can it load resources from the directory where
the VM itself came from? We want to package things such that they all
go into
jre/bin/<somedirectoryname>
with the default for that being 'default' (although it shouldn't matter).
We also want to avoid setting LD_LIBRARY_PATH and other such
externalities...
geir
Evgueni Brevnov wrote:
> Ok, I will try to teach DRLVM where to load dlls from before doing other
> things.
>
> Evgueni.
>
> On 9/1/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> Ok, but can we wack off the biggest problem first, namely that DRLVM
>> doesn't work when it's artifacts (dll's, so's) are in a subdirectory of
>> jre/bin?
>>
>> TO me, that's our biggest problem. Subtle cleanup issues are also
>> important, but not as much at this point.
>>
>> geir
>>
>> Evgueni Brevnov wrote:
>> > Hi Geir,
>> >
>> > I'm very enthusiastic about making DRLVM to work with the launcher. It
>> > requires implementation of the Invocation API to a certain extent. For
>> > example it's enougth to have only partial support for
>> > DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is
>> > necessary as well. So if there is no objections I can start working on
>> > it right now.
>> >
>> > Thanks
>> > Evgueni.
>> >
>> > On 8/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> We need to make DRLVM work with the launcher in the same way that J9
>> >> works with the launcher. It's a royal PITA to do an ant-clean and
>> have
>> >> DRLVM wiped out of the deploy/jdk/jre directory in classlib-land.
>> >>
>> >> My goal here is two fold -
>> >>
>> >> a) make it easy for people to have both DRLVM and j9 around for A/B
>> >> testing
>> >>
>> >> b) make DRLVM the default VM we use for everything
>> >>
>> >> I know that we still have the epic argument around hythread to
>> resolve,
>> >> but we can do this task first.
>> >>
>> >> Does anyone want to volunteer to take this on? If not, I'll do it,
>> but
>> >> I know that there are people out there that know DRLVM far better
>> than I
>> >> do...
>> >>
>> >> geir
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Evgueni Brevnov <ev...@gmail.com>.
Ok, I will try to teach DRLVM where to load dlls from before doing other things.
Evgueni.
On 9/1/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Ok, but can we wack off the biggest problem first, namely that DRLVM
> doesn't work when it's artifacts (dll's, so's) are in a subdirectory of
> jre/bin?
>
> TO me, that's our biggest problem. Subtle cleanup issues are also
> important, but not as much at this point.
>
> geir
>
> Evgueni Brevnov wrote:
> > Hi Geir,
> >
> > I'm very enthusiastic about making DRLVM to work with the launcher. It
> > requires implementation of the Invocation API to a certain extent. For
> > example it's enougth to have only partial support for
> > DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is
> > necessary as well. So if there is no objections I can start working on
> > it right now.
> >
> > Thanks
> > Evgueni.
> >
> > On 8/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> We need to make DRLVM work with the launcher in the same way that J9
> >> works with the launcher. It's a royal PITA to do an ant-clean and have
> >> DRLVM wiped out of the deploy/jdk/jre directory in classlib-land.
> >>
> >> My goal here is two fold -
> >>
> >> a) make it easy for people to have both DRLVM and j9 around for A/B
> >> testing
> >>
> >> b) make DRLVM the default VM we use for everything
> >>
> >> I know that we still have the epic argument around hythread to resolve,
> >> but we can do this task first.
> >>
> >> Does anyone want to volunteer to take this on? If not, I'll do it, but
> >> I know that there are people out there that know DRLVM far better than I
> >> do...
> >>
> >> geir
> >>
> >> ---------------------------------------------------------------------
> >> 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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Ok, but can we wack off the biggest problem first, namely that DRLVM
doesn't work when it's artifacts (dll's, so's) are in a subdirectory of
jre/bin?
TO me, that's our biggest problem. Subtle cleanup issues are also
important, but not as much at this point.
geir
Evgueni Brevnov wrote:
> Hi Geir,
>
> I'm very enthusiastic about making DRLVM to work with the launcher. It
> requires implementation of the Invocation API to a certain extent. For
> example it's enougth to have only partial support for
> DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is
> necessary as well. So if there is no objections I can start working on
> it right now.
>
> Thanks
> Evgueni.
>
> On 8/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> We need to make DRLVM work with the launcher in the same way that J9
>> works with the launcher. It's a royal PITA to do an ant-clean and have
>> DRLVM wiped out of the deploy/jdk/jre directory in classlib-land.
>>
>> My goal here is two fold -
>>
>> a) make it easy for people to have both DRLVM and j9 around for A/B
>> testing
>>
>> b) make DRLVM the default VM we use for everything
>>
>> I know that we still have the epic argument around hythread to resolve,
>> but we can do this task first.
>>
>> Does anyone want to volunteer to take this on? If not, I'll do it, but
>> I know that there are people out there that know DRLVM far better than I
>> do...
>>
>> geir
>>
>> ---------------------------------------------------------------------
>> 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
Re: [drlvm] DRLVM, jre/bin/default and launcher
Posted by Evgueni Brevnov <ev...@gmail.com>.
Hi Geir,
I'm very enthusiastic about making DRLVM to work with the launcher. It
requires implementation of the Invocation API to a certain extent. For
example it's enougth to have only partial support for
DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is
necessary as well. So if there is no objections I can start working on
it right now.
Thanks
Evgueni.
On 8/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> We need to make DRLVM work with the launcher in the same way that J9
> works with the launcher. It's a royal PITA to do an ant-clean and have
> DRLVM wiped out of the deploy/jdk/jre directory in classlib-land.
>
> My goal here is two fold -
>
> a) make it easy for people to have both DRLVM and j9 around for A/B testing
>
> b) make DRLVM the default VM we use for everything
>
> I know that we still have the epic argument around hythread to resolve,
> but we can do this task first.
>
> Does anyone want to volunteer to take this on? If not, I'll do it, but
> I know that there are people out there that know DRLVM far better than I
> do...
>
> geir
>
> ---------------------------------------------------------------------
> 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