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/09/08 23:32:51 UTC
[drlvm] putting kernel.jar in jre/bin/default
I'll figure this out myself if I don't get a quick answer, but I think
we should put the DRLVM kernel classes jar(s) in the same directory as
the rest of the DRLVM artifacts so that it's easy to switch between VMs
using the launcher. (J9 does this).
How does DRLVM decide where to look?
(I'm re-doing the DRLVM build to finish integrating the launcher
properly, and figure that a nice thing to add is a DRLVM-snapshot that
just drops into classlib/deploy/jdk/jre/bin the same way J9 does for
developers....
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] putting kernel.jar in jre/bin/default
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexey Varlamov wrote:
> 2006/9/11, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>>
>> Evgueni Brevnov wrote:
>>
>> > If yes then we can take vmcore.dll base path as a
>> > location of kerenel.jar.
>>
>> Sure - where will you get that? and what do you w/ .so's in unix? I've
>> come to the conclusion that the only way will be to manually run the
>> PATH (win) and LD_LIBRARY_PATH (linux)
>
> IIUC, j9 does this in astonishingly simple way - it just specifies
> "-Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar" in the
> "<vmdir>/harmonyvm.properties" file, and the launcher does the rest.
> Namely, it automatically reads that file, replaces %LAUNCHER_HOME%
> with actual location and feeds extra arguments to VM among user's
> ones.
> This solution looks sufficient for now, but it seems to be only
> partial: it does not work for pure Invocation API usecase. Besides,
> those hardcoded arguments to VM appear confusing in some cases - e.g.
> it is impossible to override kernel.jar via command-line. Also note
> hardcoded "default" vmdir.
Ok, this makes sense. Yes, the "default" is a problem. However, if a
little is good, more is better.... we could also add another env var
like LAUNCHER_HOME like VM_DIR so
-Xbootclasspath/p:%LAUNCHER_HOME%/%VM_DIR%/....
so that we can at least put it in /j9 and /drlvm - the goal here is to
be able to install both at the same time to make it easy to A/B test things.
And yes, this is problematic as you noted...
>
> As for the .so locations, I'm not sure if there is portable solution
> (parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution
> would be leave this to user - for setting JAVA_HOME or such...
Yes, LD_LIBRARY_PATH is going to be error-prone, but it's how other
resources are found - using apr_dso_load() on linux just defers to
dlopen(), which.... uses LD_LIBRARY_PATH.
geir
>
> --
> Alexey
>
>>
>> geir
>>
>> >
>> >
>> >>
>> >> geir
>> >>
>> >> Geir Magnusson Jr. wrote:
>> >> > I'll figure this out myself if I don't get a quick answer, but I
>> think
>> >> > we should put the DRLVM kernel classes jar(s) in the same
>> directory as
>> >> > the rest of the DRLVM artifacts so that it's easy to switch
>> between VMs
>> >> > using the launcher. (J9 does this).
>> >> >
>> >> > How does DRLVM decide where to look?
>> >> >
>> >> > (I'm re-doing the DRLVM build to finish integrating the launcher
>> >> > properly, and figure that a nice thing to add is a DRLVM-snapshot
>> that
>> >> > just drops into classlib/deploy/jdk/jre/bin the same way J9 does for
>> >> > developers....
>> >> >
>> >> > 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
>
---------------------------------------------------------------------
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] putting kernel.jar in jre/bin/default
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 9/11/06, Alexey Varlamov <al...@gmail.com> wrote:
> 2006/9/11, Evgueni Brevnov <ev...@gmail.com>:
> > On 9/11/06, Alexey Varlamov <al...@gmail.com> wrote:
> > > 2006/9/11, Geir Magnusson Jr. <ge...@pobox.com>:
> > > >
> > > >
> > > > Evgueni Brevnov wrote:
> > > > > On 9/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > > >> There seems to be no easy solution, other than parse LD_LIBRARY_PATH or
> > > > >> PATH...
> > > > >
> > > > > Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside
> > > > > in one directory?
> > > >
> > > > I was thinking about this for packaging - that way you can have :
> > > >
> > > > jre/
> > > > bin/
> > > > j9/
> > > > drlvm/
> > > >
> > > > and setup a symlink if you wish.
> > > >
> > > > if we have kernel.jar in jre/lib/boot as we do now, it's must less
> > > > convenient and probably error prone to switch back and forth.
> > > >
> > > > > If yes then we can take vmcore.dll base path as a
> > > > > location of kerenel.jar.
> > > >
> > > > Sure - where will you get that? and what do you w/ .so's in unix? I've
> > > > come to the conclusion that the only way will be to manually run the
> > > > PATH (win) and LD_LIBRARY_PATH (linux)
> > >
> > Geir, it seems you are right. I failed to find appropriate solution on
> > Linux. Parsing LD_LIBRARY_PATH can be an option here. Or we can use
> > deployment process to set up application specific environment
> > variable.
>
> Well, with a bit of googling I've managed to obtain the following snippet [1]:
> if (dladdr( addr, &info ) != 0)
> {
> strncpy( path, info.dli_fname, PATH_MAX );
> *(strrchr( path, '/' )) = '\0';
> }
>
> "The dladdr() function shall query the dynamic linker for information
> about the shared object containing the address addr." [2]
> Moreover, google reports about "dladdr" in a variety of manuals,
> including BSD, SGI, MacOS, Solaris etc, I've listed some of the links
> below.
> So this looks like a silver bullet for us :)
Great! It should work for us. With this approach it is possible not to
depend on LD_LIBRARY_PATH and PATH at all.
>
> [1] http://lists.trolltech.com/qt-interest/2003-11/msg00380.html
> [2] http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/baselib-dladdr-3.html
> [3] http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/dladdr.3.html
> [4] http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr4c?a=view
>
> >
> > > IIUC, j9 does this in astonishingly simple way - it just specifies
> > > "-Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar" in the
> > > "<vmdir>/harmonyvm.properties" file, and the launcher does the rest.
> > > Namely, it automatically reads that file, replaces %LAUNCHER_HOME%
> > > with actual location and feeds extra arguments to VM among user's
> > > ones.
> > > This solution looks sufficient for now, but it seems to be only
> > > partial: it does not work for pure Invocation API usecase. Besides,
> > > those hardcoded arguments to VM appear confusing in some cases - e.g.
> > > it is impossible to override kernel.jar via command-line. Also note
> > > hardcoded "default" vmdir.
> > >
> > > As for the .so locations, I'm not sure if there is portable solution
> > > (parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution
> > > would be leave this to user - for setting JAVA_HOME or such...
> > >
> > > --
> > > Alexey
> > >
> > > >
> > > > geir
> > > >
> > > > >
> > > > >
> > > > >>
> > > > >> geir
> > > > >>
> > > > >> Geir Magnusson Jr. wrote:
> > > > >> > I'll figure this out myself if I don't get a quick answer, but I think
> > > > >> > we should put the DRLVM kernel classes jar(s) in the same directory as
> > > > >> > the rest of the DRLVM artifacts so that it's easy to switch between VMs
> > > > >> > using the launcher. (J9 does this).
> > > > >> >
> > > > >> > How does DRLVM decide where to look?
> > > > >> >
> > > > >> > (I'm re-doing the DRLVM build to finish integrating the launcher
> > > > >> > properly, and figure that a nice thing to add is a DRLVM-snapshot that
> > > > >> > just drops into classlib/deploy/jdk/jre/bin the same way J9 does for
> > > > >> > developers....
> > > > >> >
> > > > >> > 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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] putting kernel.jar in jre/bin/default
Posted by Alexey Varlamov <al...@gmail.com>.
2006/9/11, Evgueni Brevnov <ev...@gmail.com>:
> On 9/11/06, Alexey Varlamov <al...@gmail.com> wrote:
> > 2006/9/11, Geir Magnusson Jr. <ge...@pobox.com>:
> > >
> > >
> > > Evgueni Brevnov wrote:
> > > > On 9/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >> There seems to be no easy solution, other than parse LD_LIBRARY_PATH or
> > > >> PATH...
> > > >
> > > > Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside
> > > > in one directory?
> > >
> > > I was thinking about this for packaging - that way you can have :
> > >
> > > jre/
> > > bin/
> > > j9/
> > > drlvm/
> > >
> > > and setup a symlink if you wish.
> > >
> > > if we have kernel.jar in jre/lib/boot as we do now, it's must less
> > > convenient and probably error prone to switch back and forth.
> > >
> > > > If yes then we can take vmcore.dll base path as a
> > > > location of kerenel.jar.
> > >
> > > Sure - where will you get that? and what do you w/ .so's in unix? I've
> > > come to the conclusion that the only way will be to manually run the
> > > PATH (win) and LD_LIBRARY_PATH (linux)
> >
> Geir, it seems you are right. I failed to find appropriate solution on
> Linux. Parsing LD_LIBRARY_PATH can be an option here. Or we can use
> deployment process to set up application specific environment
> variable.
Well, with a bit of googling I've managed to obtain the following snippet [1]:
if (dladdr( addr, &info ) != 0)
{
strncpy( path, info.dli_fname, PATH_MAX );
*(strrchr( path, '/' )) = '\0';
}
"The dladdr() function shall query the dynamic linker for information
about the shared object containing the address addr." [2]
Moreover, google reports about "dladdr" in a variety of manuals,
including BSD, SGI, MacOS, Solaris etc, I've listed some of the links
below.
So this looks like a silver bullet for us :)
[1] http://lists.trolltech.com/qt-interest/2003-11/msg00380.html
[2] http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/baselib-dladdr-3.html
[3] http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/dladdr.3.html
[4] http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr4c?a=view
>
> > IIUC, j9 does this in astonishingly simple way - it just specifies
> > "-Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar" in the
> > "<vmdir>/harmonyvm.properties" file, and the launcher does the rest.
> > Namely, it automatically reads that file, replaces %LAUNCHER_HOME%
> > with actual location and feeds extra arguments to VM among user's
> > ones.
> > This solution looks sufficient for now, but it seems to be only
> > partial: it does not work for pure Invocation API usecase. Besides,
> > those hardcoded arguments to VM appear confusing in some cases - e.g.
> > it is impossible to override kernel.jar via command-line. Also note
> > hardcoded "default" vmdir.
> >
> > As for the .so locations, I'm not sure if there is portable solution
> > (parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution
> > would be leave this to user - for setting JAVA_HOME or such...
> >
> > --
> > Alexey
> >
> > >
> > > geir
> > >
> > > >
> > > >
> > > >>
> > > >> geir
> > > >>
> > > >> Geir Magnusson Jr. wrote:
> > > >> > I'll figure this out myself if I don't get a quick answer, but I think
> > > >> > we should put the DRLVM kernel classes jar(s) in the same directory as
> > > >> > the rest of the DRLVM artifacts so that it's easy to switch between VMs
> > > >> > using the launcher. (J9 does this).
> > > >> >
> > > >> > How does DRLVM decide where to look?
> > > >> >
> > > >> > (I'm re-doing the DRLVM build to finish integrating the launcher
> > > >> > properly, and figure that a nice thing to add is a DRLVM-snapshot that
> > > >> > just drops into classlib/deploy/jdk/jre/bin the same way J9 does for
> > > >> > developers....
> > > >> >
> > > >> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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] putting kernel.jar in jre/bin/default
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 9/11/06, Alexey Varlamov <al...@gmail.com> wrote:
> 2006/9/11, Geir Magnusson Jr. <ge...@pobox.com>:
> >
> >
> > Evgueni Brevnov wrote:
> > > On 9/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >> There seems to be no easy solution, other than parse LD_LIBRARY_PATH or
> > >> PATH...
> > >
> > > Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside
> > > in one directory?
> >
> > I was thinking about this for packaging - that way you can have :
> >
> > jre/
> > bin/
> > j9/
> > drlvm/
> >
> > and setup a symlink if you wish.
> >
> > if we have kernel.jar in jre/lib/boot as we do now, it's must less
> > convenient and probably error prone to switch back and forth.
> >
> > > If yes then we can take vmcore.dll base path as a
> > > location of kerenel.jar.
> >
> > Sure - where will you get that? and what do you w/ .so's in unix? I've
> > come to the conclusion that the only way will be to manually run the
> > PATH (win) and LD_LIBRARY_PATH (linux)
>
Geir, it seems you are right. I failed to find appropriate solution on
Linux. Parsing LD_LIBRARY_PATH can be an option here. Or we can use
deployment process to set up application specific environment
variable.
> IIUC, j9 does this in astonishingly simple way - it just specifies
> "-Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar" in the
> "<vmdir>/harmonyvm.properties" file, and the launcher does the rest.
> Namely, it automatically reads that file, replaces %LAUNCHER_HOME%
> with actual location and feeds extra arguments to VM among user's
> ones.
> This solution looks sufficient for now, but it seems to be only
> partial: it does not work for pure Invocation API usecase. Besides,
> those hardcoded arguments to VM appear confusing in some cases - e.g.
> it is impossible to override kernel.jar via command-line. Also note
> hardcoded "default" vmdir.
>
> As for the .so locations, I'm not sure if there is portable solution
> (parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution
> would be leave this to user - for setting JAVA_HOME or such...
>
> --
> Alexey
>
> >
> > geir
> >
> > >
> > >
> > >>
> > >> geir
> > >>
> > >> Geir Magnusson Jr. wrote:
> > >> > I'll figure this out myself if I don't get a quick answer, but I think
> > >> > we should put the DRLVM kernel classes jar(s) in the same directory as
> > >> > the rest of the DRLVM artifacts so that it's easy to switch between VMs
> > >> > using the launcher. (J9 does this).
> > >> >
> > >> > How does DRLVM decide where to look?
> > >> >
> > >> > (I'm re-doing the DRLVM build to finish integrating the launcher
> > >> > properly, and figure that a nice thing to add is a DRLVM-snapshot that
> > >> > just drops into classlib/deploy/jdk/jre/bin the same way J9 does for
> > >> > developers....
> > >> >
> > >> > 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
>
>
---------------------------------------------------------------------
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] putting kernel.jar in jre/bin/default
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
> 2006/9/13, Alexey Varlamov <al...@gmail.com>:
<snip>
>> Hmm, I'm not sure I understand how the Harmony launcher could be
>> helpful to an adaptive VM, until the VM can detect by which launcher
>> it is invoked and adapt accordingly. But the latter is evidently
>> unnecessary complication...
>> The launcher imposes certain requirements to VM:
>> - to handle "luni" part of bootclasspath on it's own;
>> - to recognize Harmony-specifc arguments, as
>> "_org.apache.harmony.vmi.portlib";
>> And there are other implications of Harmony classlib, like explicit
>> loading of certain natives, etc. So the VM must have an adaptive
>> harmony layer anyway...
>
> And again, an Invocation-capable VM is supposed to work with arbitrary
> launcher, therefore the Harmony launcher should be minimized.
>
We should fix the launcher requirements you mention. In particular, we
should allow, but not require, the absence of the portlib argument.
Where it is not provided the classlib code should provide a default
instance.
I'll call this out in a mail new thread since it will need an extension
to the VMI functions.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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] putting kernel.jar in jre/bin/default
Posted by Alexey Varlamov <al...@gmail.com>.
2006/9/13, Alexey Varlamov <al...@gmail.com>:
> 2006/9/13, Paulex Yang <pa...@gmail.com>:
> > Alexey Varlamov wrote:
> > > 2006/9/13, Paulex Yang <pa...@gmail.com>:
> > >> Alexey Varlamov wrote:
> > >> > Looks like sending my reply failed, here is a second try:
> > >> >
> > >> >> I'm not sure I catch up what you mean, about Emma, Harmony's current
> > >> >> test coverage exclude list[1] shows that not all classes can be
> > >> >> instrumented, I don't think it is due to the position of kernel
> > >> classes.
> > >> >
> > >> > Paulex,
> > >> >
> > >> > I'm sorry for causing confusion - I was a bit wrong. I experienced
> > >> > troubles with complete overriiding via "-Xbootclasspath:" argument,
> > >> > and just prepending "-Xbootclasspath/p:" works OK. Not all kernel
> > >> > classes are instrumented due to dependencies in instrumentation code
> > >> > itself, this is of course different thing.
> > >> Agreed.
> > >> >
> > >> >>
> > >> >> Further, for the special requirement(instrument, AOP, or so),
> > >> anything
> > >> >> prevent the user to add "-Xbootclasspath/p" to replace the kernel
> > >> class
> > >> >> implementation? Or, what's the difference on this between RI and
> > >> current
> > >> >> Harmony?
> > >> >
> > >> > So the difference is that for "-Xbootclasspath:", launcher+j9 always
> > >> > stealthily prepend luni-kernel.jar to user-specified bootclasspath,
> > >> > while RI allows fully custom bootclasspath.
> > >> This is interesting. Yes, I think we should handle it, although it
> > >> probably won't work to replace the kernel class implementation due to
> > >> the VM dependency, we have no reason forbidding user to do this.
> > >>
> > >> Just had a look at how the normal bootclasspath(luni.jar, text.jar...)
> > >> is processed, the interesting thing is they are loaded by JNI_OnLoad of
> > >> hyluni.dll(libhyluni.so), with the source codes located in
> > >> modules/luni/src/native/luni/shared/luniglob.c (It is interesting
> > >> because I thought it was in launcher, but maybe the original author had
> > >> similar issues to get the absolute path of jre/lib/boot). And it takes a
> > >> straightforward way to handle the "-Xbootclasspath": if this argument is
> > >> passed in command line, just give up parsing the default bootclasspath.
> > >> I have two thoughts on this:
> > >> 1. If this is acceptable, we can deal with kernel class in similar way.
> > >> 2. Supposing we can have better solution to locate the jre path, is
> > >> there any chance to merge the both bootclasspath handling(kernel and
> > >> normal) to launcher, so that it doesn't need to deal with bootclasspath
> > >> twice?
> > >>
> > >> Or any other proposals?
> > >
> > > We had a discussion about this month ago [1], and the main argument
> > > against the launcher was "there may be several launchers, moreover
> > > bootclasspath has to be set for any application that calls
> > > JNI_CreateJavaVM". So no better place than luni natives was suggested
> > > for the shared part of the bootlclasspath. BTW, there is reliability
> > > fix HARMONY-1243 related to this and still unresolved...
> > OK, I'll look at it.
> > >
> > > But as kernel classes packaging is VM-specific, the VM should take
> > > care of them. Evidently the same argument about launcher applies to
> > > kernels as well, so current way with harmonyvm.properties is a sort of
> > > workaround anyway.
> > > And to handle the "-Xbooclasspath:" issue, there should be double
> > > filtering: check user-supplied arguments then filter autoloaded ones
> > > from harmonyvm.properties. Smells not really good ;).
> > That's what I meant...
> > > More logical would be to get rid of handling harmonyvm.properties in
> > > launcher entirely, leaving this to VM if it needs it.
> > I thought about this, but launcher actually uses standard invocation API
> > to create VM, so if VM's invocation API implementation takes care of the
> > kernel class(which are part of Harmony VMI), it's a little difficult for
> > VM vendor to provide an adaptive VM, adaptive here means it can adapt
> > Harmony classlib as well as others without too much effort, say, GNU
> > Classpath(or maybe Sun's Open Sourced Classlib). I still prefer to
> > handle the Harmony VMI related things in *Harmony* Launcher.
>
> Hmm, I'm not sure I understand how the Harmony launcher could be
> helpful to an adaptive VM, until the VM can detect by which launcher
> it is invoked and adapt accordingly. But the latter is evidently
> unnecessary complication...
> The launcher imposes certain requirements to VM:
> - to handle "luni" part of bootclasspath on it's own;
> - to recognize Harmony-specifc arguments, as "_org.apache.harmony.vmi.portlib";
> And there are other implications of Harmony classlib, like explicit
> loading of certain natives, etc. So the VM must have an adaptive
> harmony layer anyway...
>
And again, an Invocation-capable VM is supposed to work with arbitrary
launcher, therefore the Harmony launcher should be minimized.
> >
> > And anyway, if the normal bootclasspath should be taken care of in luni,
> > while kernel bootclasspath must be dealed with elsewhere, the double
> > filtering is hard to avoid.
> > >
> > > [1]
> > > http://thread.gmane.org/gmane.comp.java.harmony.devel/11776/focus=11818
> > >
> > >> >
> > >> > --
> > >> > Alexey
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> > 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
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Paulex Yang
> > >> China Software Development Lab
> > >> IBM
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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
> > >
> > >
> >
> >
> > --
> > Paulex Yang
> > China Software Development Lab
> > IBM
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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] putting kernel.jar in jre/bin/default
Posted by Alexey Varlamov <al...@gmail.com>.
2006/9/13, Paulex Yang <pa...@gmail.com>:
> Alexey Varlamov wrote:
> > 2006/9/13, Paulex Yang <pa...@gmail.com>:
> >> Alexey Varlamov wrote:
> >> > Looks like sending my reply failed, here is a second try:
> >> >
> >> >> I'm not sure I catch up what you mean, about Emma, Harmony's current
> >> >> test coverage exclude list[1] shows that not all classes can be
> >> >> instrumented, I don't think it is due to the position of kernel
> >> classes.
> >> >
> >> > Paulex,
> >> >
> >> > I'm sorry for causing confusion - I was a bit wrong. I experienced
> >> > troubles with complete overriiding via "-Xbootclasspath:" argument,
> >> > and just prepending "-Xbootclasspath/p:" works OK. Not all kernel
> >> > classes are instrumented due to dependencies in instrumentation code
> >> > itself, this is of course different thing.
> >> Agreed.
> >> >
> >> >>
> >> >> Further, for the special requirement(instrument, AOP, or so),
> >> anything
> >> >> prevent the user to add "-Xbootclasspath/p" to replace the kernel
> >> class
> >> >> implementation? Or, what's the difference on this between RI and
> >> current
> >> >> Harmony?
> >> >
> >> > So the difference is that for "-Xbootclasspath:", launcher+j9 always
> >> > stealthily prepend luni-kernel.jar to user-specified bootclasspath,
> >> > while RI allows fully custom bootclasspath.
> >> This is interesting. Yes, I think we should handle it, although it
> >> probably won't work to replace the kernel class implementation due to
> >> the VM dependency, we have no reason forbidding user to do this.
> >>
> >> Just had a look at how the normal bootclasspath(luni.jar, text.jar...)
> >> is processed, the interesting thing is they are loaded by JNI_OnLoad of
> >> hyluni.dll(libhyluni.so), with the source codes located in
> >> modules/luni/src/native/luni/shared/luniglob.c (It is interesting
> >> because I thought it was in launcher, but maybe the original author had
> >> similar issues to get the absolute path of jre/lib/boot). And it takes a
> >> straightforward way to handle the "-Xbootclasspath": if this argument is
> >> passed in command line, just give up parsing the default bootclasspath.
> >> I have two thoughts on this:
> >> 1. If this is acceptable, we can deal with kernel class in similar way.
> >> 2. Supposing we can have better solution to locate the jre path, is
> >> there any chance to merge the both bootclasspath handling(kernel and
> >> normal) to launcher, so that it doesn't need to deal with bootclasspath
> >> twice?
> >>
> >> Or any other proposals?
> >
> > We had a discussion about this month ago [1], and the main argument
> > against the launcher was "there may be several launchers, moreover
> > bootclasspath has to be set for any application that calls
> > JNI_CreateJavaVM". So no better place than luni natives was suggested
> > for the shared part of the bootlclasspath. BTW, there is reliability
> > fix HARMONY-1243 related to this and still unresolved...
> OK, I'll look at it.
> >
> > But as kernel classes packaging is VM-specific, the VM should take
> > care of them. Evidently the same argument about launcher applies to
> > kernels as well, so current way with harmonyvm.properties is a sort of
> > workaround anyway.
> > And to handle the "-Xbooclasspath:" issue, there should be double
> > filtering: check user-supplied arguments then filter autoloaded ones
> > from harmonyvm.properties. Smells not really good ;).
> That's what I meant...
> > More logical would be to get rid of handling harmonyvm.properties in
> > launcher entirely, leaving this to VM if it needs it.
> I thought about this, but launcher actually uses standard invocation API
> to create VM, so if VM's invocation API implementation takes care of the
> kernel class(which are part of Harmony VMI), it's a little difficult for
> VM vendor to provide an adaptive VM, adaptive here means it can adapt
> Harmony classlib as well as others without too much effort, say, GNU
> Classpath(or maybe Sun's Open Sourced Classlib). I still prefer to
> handle the Harmony VMI related things in *Harmony* Launcher.
Hmm, I'm not sure I understand how the Harmony launcher could be
helpful to an adaptive VM, until the VM can detect by which launcher
it is invoked and adapt accordingly. But the latter is evidently
unnecessary complication...
The launcher imposes certain requirements to VM:
- to handle "luni" part of bootclasspath on it's own;
- to recognize Harmony-specifc arguments, as "_org.apache.harmony.vmi.portlib";
And there are other implications of Harmony classlib, like explicit
loading of certain natives, etc. So the VM must have an adaptive
harmony layer anyway...
>
> And anyway, if the normal bootclasspath should be taken care of in luni,
> while kernel bootclasspath must be dealed with elsewhere, the double
> filtering is hard to avoid.
> >
> > [1]
> > http://thread.gmane.org/gmane.comp.java.harmony.devel/11776/focus=11818
> >
> >> >
> >> > --
> >> > Alexey
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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
> >> >
> >> >
> >>
> >>
> >> --
> >> Paulex Yang
> >> China Software Development Lab
> >> IBM
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> 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] putting kernel.jar in jre/bin/default
Posted by Paulex Yang <pa...@gmail.com>.
Alexey Varlamov wrote:
> 2006/9/13, Paulex Yang <pa...@gmail.com>:
>> Alexey Varlamov wrote:
>> > Looks like sending my reply failed, here is a second try:
>> >
>> >> I'm not sure I catch up what you mean, about Emma, Harmony's current
>> >> test coverage exclude list[1] shows that not all classes can be
>> >> instrumented, I don't think it is due to the position of kernel
>> classes.
>> >
>> > Paulex,
>> >
>> > I'm sorry for causing confusion - I was a bit wrong. I experienced
>> > troubles with complete overriiding via "-Xbootclasspath:" argument,
>> > and just prepending "-Xbootclasspath/p:" works OK. Not all kernel
>> > classes are instrumented due to dependencies in instrumentation code
>> > itself, this is of course different thing.
>> Agreed.
>> >
>> >>
>> >> Further, for the special requirement(instrument, AOP, or so),
>> anything
>> >> prevent the user to add "-Xbootclasspath/p" to replace the kernel
>> class
>> >> implementation? Or, what's the difference on this between RI and
>> current
>> >> Harmony?
>> >
>> > So the difference is that for "-Xbootclasspath:", launcher+j9 always
>> > stealthily prepend luni-kernel.jar to user-specified bootclasspath,
>> > while RI allows fully custom bootclasspath.
>> This is interesting. Yes, I think we should handle it, although it
>> probably won't work to replace the kernel class implementation due to
>> the VM dependency, we have no reason forbidding user to do this.
>>
>> Just had a look at how the normal bootclasspath(luni.jar, text.jar...)
>> is processed, the interesting thing is they are loaded by JNI_OnLoad of
>> hyluni.dll(libhyluni.so), with the source codes located in
>> modules/luni/src/native/luni/shared/luniglob.c (It is interesting
>> because I thought it was in launcher, but maybe the original author had
>> similar issues to get the absolute path of jre/lib/boot). And it takes a
>> straightforward way to handle the "-Xbootclasspath": if this argument is
>> passed in command line, just give up parsing the default bootclasspath.
>> I have two thoughts on this:
>> 1. If this is acceptable, we can deal with kernel class in similar way.
>> 2. Supposing we can have better solution to locate the jre path, is
>> there any chance to merge the both bootclasspath handling(kernel and
>> normal) to launcher, so that it doesn't need to deal with bootclasspath
>> twice?
>>
>> Or any other proposals?
>
> We had a discussion about this month ago [1], and the main argument
> against the launcher was "there may be several launchers, moreover
> bootclasspath has to be set for any application that calls
> JNI_CreateJavaVM". So no better place than luni natives was suggested
> for the shared part of the bootlclasspath. BTW, there is reliability
> fix HARMONY-1243 related to this and still unresolved...
OK, I'll look at it.
>
> But as kernel classes packaging is VM-specific, the VM should take
> care of them. Evidently the same argument about launcher applies to
> kernels as well, so current way with harmonyvm.properties is a sort of
> workaround anyway.
> And to handle the "-Xbooclasspath:" issue, there should be double
> filtering: check user-supplied arguments then filter autoloaded ones
> from harmonyvm.properties. Smells not really good ;).
That's what I meant...
> More logical would be to get rid of handling harmonyvm.properties in
> launcher entirely, leaving this to VM if it needs it.
I thought about this, but launcher actually uses standard invocation API
to create VM, so if VM's invocation API implementation takes care of the
kernel class(which are part of Harmony VMI), it's a little difficult for
VM vendor to provide an adaptive VM, adaptive here means it can adapt
Harmony classlib as well as others without too much effort, say, GNU
Classpath(or maybe Sun's Open Sourced Classlib). I still prefer to
handle the Harmony VMI related things in *Harmony* Launcher.
And anyway, if the normal bootclasspath should be taken care of in luni,
while kernel bootclasspath must be dealed with elsewhere, the double
filtering is hard to avoid,
>
> [1]
> http://thread.gmane.org/gmane.comp.java.harmony.devel/11776/focus=11818
>
>> >
>> > --
>> > Alexey
>> >
>> > ---------------------------------------------------------------------
>> > 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
>> >
>> >
>>
>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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] putting kernel.jar in jre/bin/default
Posted by Alexey Varlamov <al...@gmail.com>.
2006/9/13, Paulex Yang <pa...@gmail.com>:
> Alexey Varlamov wrote:
> > Looks like sending my reply failed, here is a second try:
> >
> >> I'm not sure I catch up what you mean, about Emma, Harmony's current
> >> test coverage exclude list[1] shows that not all classes can be
> >> instrumented, I don't think it is due to the position of kernel classes.
> >
> > Paulex,
> >
> > I'm sorry for causing confusion - I was a bit wrong. I experienced
> > troubles with complete overriiding via "-Xbootclasspath:" argument,
> > and just prepending "-Xbootclasspath/p:" works OK. Not all kernel
> > classes are instrumented due to dependencies in instrumentation code
> > itself, this is of course different thing.
> Agreed.
> >
> >>
> >> Further, for the special requirement(instrument, AOP, or so), anything
> >> prevent the user to add "-Xbootclasspath/p" to replace the kernel class
> >> implementation? Or, what's the difference on this between RI and current
> >> Harmony?
> >
> > So the difference is that for "-Xbootclasspath:", launcher+j9 always
> > stealthily prepend luni-kernel.jar to user-specified bootclasspath,
> > while RI allows fully custom bootclasspath.
> This is interesting. Yes, I think we should handle it, although it
> probably won't work to replace the kernel class implementation due to
> the VM dependency, we have no reason forbidding user to do this.
>
> Just had a look at how the normal bootclasspath(luni.jar, text.jar...)
> is processed, the interesting thing is they are loaded by JNI_OnLoad of
> hyluni.dll(libhyluni.so), with the source codes located in
> modules/luni/src/native/luni/shared/luniglob.c (It is interesting
> because I thought it was in launcher, but maybe the original author had
> similar issues to get the absolute path of jre/lib/boot). And it takes a
> straightforward way to handle the "-Xbootclasspath": if this argument is
> passed in command line, just give up parsing the default bootclasspath.
> I have two thoughts on this:
> 1. If this is acceptable, we can deal with kernel class in similar way.
> 2. Supposing we can have better solution to locate the jre path, is
> there any chance to merge the both bootclasspath handling(kernel and
> normal) to launcher, so that it doesn't need to deal with bootclasspath
> twice?
>
> Or any other proposals?
We had a discussion about this month ago [1], and the main argument
against the launcher was "there may be several launchers, moreover
bootclasspath has to be set for any application that calls
JNI_CreateJavaVM". So no better place than luni natives was suggested
for the shared part of the bootlclasspath. BTW, there is reliability
fix HARMONY-1243 related to this and still unresolved...
But as kernel classes packaging is VM-specific, the VM should take
care of them. Evidently the same argument about launcher applies to
kernels as well, so current way with harmonyvm.properties is a sort of
workaround anyway.
And to handle the "-Xbooclasspath:" issue, there should be double
filtering: check user-supplied arguments then filter autoloaded ones
from harmonyvm.properties. Smells not really good ;).
More logical would be to get rid of handling harmonyvm.properties in
launcher entirely, leaving this to VM if it needs it.
[1] http://thread.gmane.org/gmane.comp.java.harmony.devel/11776/focus=11818
> >
> > --
> > Alexey
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> 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] putting kernel.jar in jre/bin/default
Posted by Paulex Yang <pa...@gmail.com>.
Alexey Varlamov wrote:
> Looks like sending my reply failed, here is a second try:
>
>> I'm not sure I catch up what you mean, about Emma, Harmony's current
>> test coverage exclude list[1] shows that not all classes can be
>> instrumented, I don't think it is due to the position of kernel classes.
>
> Paulex,
>
> I'm sorry for causing confusion - I was a bit wrong. I experienced
> troubles with complete overriiding via "-Xbootclasspath:" argument,
> and just prepending "-Xbootclasspath/p:" works OK. Not all kernel
> classes are instrumented due to dependencies in instrumentation code
> itself, this is of course different thing.
Agreed.
>
>>
>> Further, for the special requirement(instrument, AOP, or so), anything
>> prevent the user to add "-Xbootclasspath/p" to replace the kernel class
>> implementation? Or, what's the difference on this between RI and current
>> Harmony?
>
> So the difference is that for "-Xbootclasspath:", launcher+j9 always
> stealthily prepend luni-kernel.jar to user-specified bootclasspath,
> while RI allows fully custom bootclasspath.
This is interesting. Yes, I think we should handle it, although it
probably won't work to replace the kernel class implementation due to
the VM dependency, we have no reason forbidding user to do this.
Just had a look at how the normal bootclasspath(luni.jar, text.jar...)
is processed, the interesting thing is they are loaded by JNI_OnLoad of
hyluni.dll(libhyluni.so), with the source codes located in
modules/luni/src/native/luni/shared/luniglob.c (It is interesting
because I thought it was in launcher, but maybe the original author had
similar issues to get the absolute path of jre/lib/boot). And it takes a
straightforward way to handle the "-Xbootclasspath": if this argument is
passed in command line, just give up parsing the default bootclasspath.
I have two thoughts on this:
1. If this is acceptable, we can deal with kernel class in similar way.
2. Supposing we can have better solution to locate the jre path, is
there any chance to merge the both bootclasspath handling(kernel and
normal) to launcher, so that it doesn't need to deal with bootclasspath
twice?
Or any other proposals?
>
> --
> Alexey
>
> ---------------------------------------------------------------------
> 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
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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] putting kernel.jar in jre/bin/default
Posted by Alexey Varlamov <al...@gmail.com>.
Looks like sending my reply failed, here is a second try:
> I'm not sure I catch up what you mean, about Emma, Harmony's current
> test coverage exclude list[1] shows that not all classes can be
> instrumented, I don't think it is due to the position of kernel classes.
Paulex,
I'm sorry for causing confusion - I was a bit wrong. I experienced
troubles with complete overriiding via "-Xbootclasspath:" argument,
and just prepending "-Xbootclasspath/p:" works OK. Not all kernel
classes are instrumented due to dependencies in instrumentation code
itself, this is of course different thing.
>
> Further, for the special requirement(instrument, AOP, or so), anything
> prevent the user to add "-Xbootclasspath/p" to replace the kernel class
> implementation? Or, what's the difference on this between RI and current
> Harmony?
So the difference is that for "-Xbootclasspath:", launcher+j9 always
stealthily prepend luni-kernel.jar to user-specified bootclasspath,
while RI allows fully custom bootclasspath.
--
Alexey
---------------------------------------------------------------------
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] putting kernel.jar in jre/bin/default
Posted by Paulex Yang <pa...@gmail.com>.
Alexey Varlamov wrote:
> 2006/9/11, Paulex Yang <pa...@gmail.com>:
>> Alexey Varlamov wrote:
>> > 2006/9/11, Geir Magnusson Jr. <ge...@pobox.com>:
>> >>
>> >>
>> >> Evgueni Brevnov wrote:
>> >> > On 9/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> >> There seems to be no easy solution, other than parse
>> >> LD_LIBRARY_PATH or
>> >> >> PATH...
>> >> >
>> >> > Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always
>> reside
>> >> > in one directory?
>> >>
>> >> I was thinking about this for packaging - that way you can have :
>> >>
>> >> jre/
>> >> bin/
>> >> j9/
>> >> drlvm/
>> >>
>> >> and setup a symlink if you wish.
>> >>
>> >> if we have kernel.jar in jre/lib/boot as we do now, it's must less
>> >> convenient and probably error prone to switch back and forth.
>> >>
>> >> > If yes then we can take vmcore.dll base path as a
>> >> > location of kerenel.jar.
>> >>
>> >> Sure - where will you get that? and what do you w/ .so's in
>> unix? I've
>> >> come to the conclusion that the only way will be to manually run the
>> >> PATH (win) and LD_LIBRARY_PATH (linux)
>> >
>> > IIUC, j9 does this in astonishingly simple way - it just specifies
>> > "-Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar" in the
>> > "<vmdir>/harmonyvm.properties" file, and the launcher does the rest.
>> > Namely, it automatically reads that file, replaces %LAUNCHER_HOME%
>> > with actual location and feeds extra arguments to VM among user's
>> > ones.
>> > This solution looks sufficient for now, but it seems to be only
>> > partial: it does not work for pure Invocation API
>> > usecase.Besides,those hardcoded arguments to VM appear confusing in
>> > some cases - e.g.
>> > it is impossible to override kernel.jar via command-line.
>> Is it necessary to override the kernel.jar via command-line? The kernel
>> class is provided by VM, so it is natural to locate it by VM specific
>> property file.
>
> The first example which came to mind, how could you instrument the
> kernel classes, say for coverage analysis by emma or custom profiling?
> I'm sure there are more usecases, but anyway this is generally adopted
> behaviour and not following it may be far more disappointing than
> exception message incompatibility which we care so much ;)
I'm not sure I catch up what you mean, about Emma, Harmony's current
test coverage exclude list[1] shows that not all classes can be
instrumented, I don't think it is due to the position of kernel classes.
Further, for the special requirement(instrument, AOP, or so), anything
prevent the user to add "-Xbootclasspath/p" to replace the kernel class
implementation? Or, what's the difference on this between RI and current
Harmony?
[1] http://viv.byethost15.com/exclude.list
>
>> > Also note hardcoded "default" vmdir.
>> Agree, "default" should be replaced by some variables(%vmdir% or so), so
>> it is easier to move VME to another directory.
> OK, I will file a JIRA for this.
>
> --
> Regards,
> Alexey
>
> ---------------------------------------------------------------------
> 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
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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] putting kernel.jar in jre/bin/default
Posted by Alexey Varlamov <al...@gmail.com>.
2006/9/11, Paulex Yang <pa...@gmail.com>:
> Alexey Varlamov wrote:
> > 2006/9/11, Geir Magnusson Jr. <ge...@pobox.com>:
> >>
> >>
> >> Evgueni Brevnov wrote:
> >> > On 9/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> >> There seems to be no easy solution, other than parse
> >> LD_LIBRARY_PATH or
> >> >> PATH...
> >> >
> >> > Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside
> >> > in one directory?
> >>
> >> I was thinking about this for packaging - that way you can have :
> >>
> >> jre/
> >> bin/
> >> j9/
> >> drlvm/
> >>
> >> and setup a symlink if you wish.
> >>
> >> if we have kernel.jar in jre/lib/boot as we do now, it's must less
> >> convenient and probably error prone to switch back and forth.
> >>
> >> > If yes then we can take vmcore.dll base path as a
> >> > location of kerenel.jar.
> >>
> >> Sure - where will you get that? and what do you w/ .so's in unix? I've
> >> come to the conclusion that the only way will be to manually run the
> >> PATH (win) and LD_LIBRARY_PATH (linux)
> >
> > IIUC, j9 does this in astonishingly simple way - it just specifies
> > "-Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar" in the
> > "<vmdir>/harmonyvm.properties" file, and the launcher does the rest.
> > Namely, it automatically reads that file, replaces %LAUNCHER_HOME%
> > with actual location and feeds extra arguments to VM among user's
> > ones.
> > This solution looks sufficient for now, but it seems to be only
> > partial: it does not work for pure Invocation API
> > usecase.Besides,those hardcoded arguments to VM appear confusing in
> > some cases - e.g.
> > it is impossible to override kernel.jar via command-line.
> Is it necessary to override the kernel.jar via command-line? The kernel
> class is provided by VM, so it is natural to locate it by VM specific
> property file.
The first example which came to mind, how could you instrument the
kernel classes, say for coverage analysis by emma or custom profiling?
I'm sure there are more usecases, but anyway this is generally adopted
behaviour and not following it may be far more disappointing than
exception message incompatibility which we care so much ;)
> > Also note hardcoded "default" vmdir.
> Agree, "default" should be replaced by some variables(%vmdir% or so), so
> it is easier to move VME to another directory.
OK, I will file a JIRA for this.
--
Regards,
Alexey
---------------------------------------------------------------------
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] putting kernel.jar in jre/bin/default
Posted by Paulex Yang <pa...@gmail.com>.
Alexey Varlamov wrote:
> 2006/9/11, Geir Magnusson Jr. <ge...@pobox.com>:
>>
>>
>> Evgueni Brevnov wrote:
>> > On 9/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> There seems to be no easy solution, other than parse
>> LD_LIBRARY_PATH or
>> >> PATH...
>> >
>> > Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside
>> > in one directory?
>>
>> I was thinking about this for packaging - that way you can have :
>>
>> jre/
>> bin/
>> j9/
>> drlvm/
>>
>> and setup a symlink if you wish.
>>
>> if we have kernel.jar in jre/lib/boot as we do now, it's must less
>> convenient and probably error prone to switch back and forth.
>>
>> > If yes then we can take vmcore.dll base path as a
>> > location of kerenel.jar.
>>
>> Sure - where will you get that? and what do you w/ .so's in unix? I've
>> come to the conclusion that the only way will be to manually run the
>> PATH (win) and LD_LIBRARY_PATH (linux)
>
> IIUC, j9 does this in astonishingly simple way - it just specifies
> "-Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar" in the
> "<vmdir>/harmonyvm.properties" file, and the launcher does the rest.
> Namely, it automatically reads that file, replaces %LAUNCHER_HOME%
> with actual location and feeds extra arguments to VM among user's
> ones.
> This solution looks sufficient for now, but it seems to be only
> partial: it does not work for pure Invocation API
> usecase.Besides,those hardcoded arguments to VM appear confusing in
> some cases - e.g.
> it is impossible to override kernel.jar via command-line.
Is it necessary to override the kernel.jar via command-line? The kernel
class is provided by VM, so it is natural to locate it by VM specific
property file.
> Also note hardcoded "default" vmdir.
Agree, "default" should be replaced by some variables(%vmdir% or so), so
it is easier to move VME to another directory.
>
> As for the .so locations, I'm not sure if there is portable solution
> (parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution
> would be leave this to user - for setting JAVA_HOME or such...
>
> --
> Alexey
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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] putting kernel.jar in jre/bin/default
Posted by Alexey Varlamov <al...@gmail.com>.
2006/9/11, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Evgueni Brevnov wrote:
> > On 9/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> There seems to be no easy solution, other than parse LD_LIBRARY_PATH or
> >> PATH...
> >
> > Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside
> > in one directory?
>
> I was thinking about this for packaging - that way you can have :
>
> jre/
> bin/
> j9/
> drlvm/
>
> and setup a symlink if you wish.
>
> if we have kernel.jar in jre/lib/boot as we do now, it's must less
> convenient and probably error prone to switch back and forth.
>
> > If yes then we can take vmcore.dll base path as a
> > location of kerenel.jar.
>
> Sure - where will you get that? and what do you w/ .so's in unix? I've
> come to the conclusion that the only way will be to manually run the
> PATH (win) and LD_LIBRARY_PATH (linux)
IIUC, j9 does this in astonishingly simple way - it just specifies
"-Xbootclasspath/p:%LAUNCHER_HOME%/default/luni-kernel.jar" in the
"<vmdir>/harmonyvm.properties" file, and the launcher does the rest.
Namely, it automatically reads that file, replaces %LAUNCHER_HOME%
with actual location and feeds extra arguments to VM among user's
ones.
This solution looks sufficient for now, but it seems to be only
partial: it does not work for pure Invocation API usecase. Besides,
those hardcoded arguments to VM appear confusing in some cases - e.g.
it is impossible to override kernel.jar via command-line. Also note
hardcoded "default" vmdir.
As for the .so locations, I'm not sure if there is portable solution
(parsing LD_LIBRARY_PATH looks error-prone). Maybe better solution
would be leave this to user - for setting JAVA_HOME or such...
--
Alexey
>
> geir
>
> >
> >
> >>
> >> geir
> >>
> >> Geir Magnusson Jr. wrote:
> >> > I'll figure this out myself if I don't get a quick answer, but I think
> >> > we should put the DRLVM kernel classes jar(s) in the same directory as
> >> > the rest of the DRLVM artifacts so that it's easy to switch between VMs
> >> > using the launcher. (J9 does this).
> >> >
> >> > How does DRLVM decide where to look?
> >> >
> >> > (I'm re-doing the DRLVM build to finish integrating the launcher
> >> > properly, and figure that a nice thing to add is a DRLVM-snapshot that
> >> > just drops into classlib/deploy/jdk/jre/bin the same way J9 does for
> >> > developers....
> >> >
> >> > 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] putting kernel.jar in jre/bin/default
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Evgueni Brevnov wrote:
> On 9/11/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>>
>> Evgueni Brevnov wrote:
>> > If yes then we can take vmcore.dll base path as a
>> > location of kerenel.jar.
>>
>> Sure - where will you get that? and what do you w/ .so's in unix? I've
>> come to the conclusion that the only way will be to manually run the
>> PATH (win) and LD_LIBRARY_PATH (linux)
>>
>> geir
>
> There is GetModuleBaseName function on Windows. So we call LoadLobrary
> to get vmcore.dll's handle and pass it to GetModuleBaseName to get a
> base path. It seems to be possible to achieve that on Linux as well...
>
Great - tell me how. I'm lazy.
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] putting kernel.jar in jre/bin/default
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 9/11/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> Evgueni Brevnov wrote:
> > On 9/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> There seems to be no easy solution, other than parse LD_LIBRARY_PATH or
> >> PATH...
> >
> > Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside
> > in one directory?
>
> I was thinking about this for packaging - that way you can have :
>
> jre/
> bin/
> j9/
> drlvm/
>
> and setup a symlink if you wish.
>
> if we have kernel.jar in jre/lib/boot as we do now, it's must less
> convenient and probably error prone to switch back and forth.
>
> > If yes then we can take vmcore.dll base path as a
> > location of kerenel.jar.
>
> Sure - where will you get that? and what do you w/ .so's in unix? I've
> come to the conclusion that the only way will be to manually run the
> PATH (win) and LD_LIBRARY_PATH (linux)
>
> geir
There is GetModuleBaseName function on Windows. So we call LoadLobrary
to get vmcore.dll's handle and pass it to GetModuleBaseName to get a
base path. It seems to be possible to achieve that on Linux as well...
Evgueni
>
> >
> >
> >>
> >> geir
> >>
> >> Geir Magnusson Jr. wrote:
> >> > I'll figure this out myself if I don't get a quick answer, but I think
> >> > we should put the DRLVM kernel classes jar(s) in the same directory as
> >> > the rest of the DRLVM artifacts so that it's easy to switch between VMs
> >> > using the launcher. (J9 does this).
> >> >
> >> > How does DRLVM decide where to look?
> >> >
> >> > (I'm re-doing the DRLVM build to finish integrating the launcher
> >> > properly, and figure that a nice thing to add is a DRLVM-snapshot that
> >> > just drops into classlib/deploy/jdk/jre/bin the same way J9 does for
> >> > developers....
> >> >
> >> > 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] putting kernel.jar in jre/bin/default
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Evgueni Brevnov wrote:
> On 9/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> There seems to be no easy solution, other than parse LD_LIBRARY_PATH or
>> PATH...
>
> Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside
> in one directory?
I was thinking about this for packaging - that way you can have :
jre/
bin/
j9/
drlvm/
and setup a symlink if you wish.
if we have kernel.jar in jre/lib/boot as we do now, it's must less
convenient and probably error prone to switch back and forth.
> If yes then we can take vmcore.dll base path as a
> location of kerenel.jar.
Sure - where will you get that? and what do you w/ .so's in unix? I've
come to the conclusion that the only way will be to manually run the
PATH (win) and LD_LIBRARY_PATH (linux)
geir
>
>
>>
>> geir
>>
>> Geir Magnusson Jr. wrote:
>> > I'll figure this out myself if I don't get a quick answer, but I think
>> > we should put the DRLVM kernel classes jar(s) in the same directory as
>> > the rest of the DRLVM artifacts so that it's easy to switch between VMs
>> > using the launcher. (J9 does this).
>> >
>> > How does DRLVM decide where to look?
>> >
>> > (I'm re-doing the DRLVM build to finish integrating the launcher
>> > properly, and figure that a nice thing to add is a DRLVM-snapshot that
>> > just drops into classlib/deploy/jdk/jre/bin the same way J9 does for
>> > developers....
>> >
>> > 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] putting kernel.jar in jre/bin/default
Posted by Evgueni Brevnov <ev...@gmail.com>.
On 9/9/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> There seems to be no easy solution, other than parse LD_LIBRARY_PATH or
> PATH...
Is vmcore.dll (now harmonyvm.dll) and kernel.jar should always reside
in one directory? If yes then we can take vmcore.dll base path as a
location of kerenel.jar.
>
> geir
>
> Geir Magnusson Jr. wrote:
> > I'll figure this out myself if I don't get a quick answer, but I think
> > we should put the DRLVM kernel classes jar(s) in the same directory as
> > the rest of the DRLVM artifacts so that it's easy to switch between VMs
> > using the launcher. (J9 does this).
> >
> > How does DRLVM decide where to look?
> >
> > (I'm re-doing the DRLVM build to finish integrating the launcher
> > properly, and figure that a nice thing to add is a DRLVM-snapshot that
> > just drops into classlib/deploy/jdk/jre/bin the same way J9 does for
> > developers....
> >
> > 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] putting kernel.jar in jre/bin/default
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
There seems to be no easy solution, other than parse LD_LIBRARY_PATH or
PATH...
geir
Geir Magnusson Jr. wrote:
> I'll figure this out myself if I don't get a quick answer, but I think
> we should put the DRLVM kernel classes jar(s) in the same directory as
> the rest of the DRLVM artifacts so that it's easy to switch between VMs
> using the launcher. (J9 does this).
>
> How does DRLVM decide where to look?
>
> (I'm re-doing the DRLVM build to finish integrating the launcher
> properly, and figure that a nice thing to add is a DRLVM-snapshot that
> just drops into classlib/deploy/jdk/jre/bin the same way J9 does for
> developers....
>
> 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