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 15:15:21 GMT
2006/9/13, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> 2006/9/13, Paulex Yang <paulex.yang@gmail.com>:
> > 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.
>
> 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


Mime
View raw message