harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm] putting kernel.jar in jre/bin/default
Date Wed, 13 Sep 2006 06:14:04 GMT
2006/9/13, Paulex Yang <paulex.yang@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


Mime
View raw message