2006/9/13, Paulex Yang <[EMAIL PROTECTED]>:
Alexey Varlamov wrote: > 2006/9/13, Paulex Yang <[EMAIL PROTECTED]>: >> 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: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> >> -- >> Paulex Yang >> China Software Development Lab >> IBM >> >> >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Paulex Yang China Software Development Lab IBM --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
