harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [drlvm] putting kernel.jar in jre/bin/default
Date Wed, 13 Sep 2006 07:44:39 GMT
Alexey Varlamov wrote:
> 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...
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


Mime
View raw message