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] Non-bug difference HARMONY-1688?
Date Fri, 13 Oct 2006 09:34:31 GMT
2006/10/13, Eugene Ostrovsky <eugene.s.ostrovsky@gmail.com>:
> Actually situation with initiating loaders is a little bit more complicated.
> in VM Spec there are two distinct terms:
> 1. 'Initiating' class loader - defined in
> ($5.3<http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#72007>)
> :
> When one class loader delegates to another class loader, the loader that
> initiates the loading is not necessarily the same loader that completes the
> loading and defines the class. If L creates C, either by defining it
> directly or by delegation, we say that L *initiates* loading of C or,
> equivalently, that L is an *initiating loader* of C.
> 2. Class loader 'recorded as initiating' by VM.
>
> According to spec (and experimenting with RI VM) VM should record loader as
> initiating only in cases when loading is initiated from VM itself. I.e. VM
> shold not record when loading is performed from java (e.g. invocation of
> Class.forName(), ClassLoader.loadClass(). etc..).

All the more, we finally have confidence that this issue has nothing
to do on the Java side :). Thanks for investigation!

>
> Patch for Vm to support recording class loaders as initiating will be
> provided soon. But I'm afraid it won't fix the H-1688 problem, since VM
> can't control delegation mechanism in user defined class loaders.

It will for sure: what happens there is usual resolution of a constant
pool reference within default delegation model. And accordingly to
your conclusion above, RI  just does not care about alternative
delegation models, so neither do we (now).

>
> On 10/9/06, Alexey Varlamov < alexey.v.varlamov@gmail.com> wrote:
> >
> > 2006/10/9, Alexey Varlamov < alexey.v.varlamov@gmail.com>:
> > > 2006/10/9, Alexey Varlamov <alexey.v.varlamov@gmail.com >:
> > > > 2006/10/9, Pavel Pervov < pmcfirst@gmail.com>:
> > > > > Commenting on (1) I should note, that VM generally can't determine
> > the fact
> > > > > of "initiating" class loading; it can only be done in Java (except
> > bootstrap
> > > > > class loader, of course).
> > > > I presume you mean cases of direct calls to loadClass() from executed
> > > > Java code. Well, the same way VM loads array classes on its own, not
> > > > resorting to Java loader instance. So AFAIU, neither VM nor Java have
> > > > 100% chance to register initiating loading singly on their own.
> > > >
> > > Hey, I found the clear specification on (1)! Look at JVMS 2nd ed, Para
> > > 5.3.2 - 5.3.3, it reads:
> > > "First, the Java virtual machine determines whether L has already been
> > > recorded as an initiating loader of a class or interface denoted by N.
> > > If so, this class or interface is C, and no class creation is
> > > necessary.
> > > Otherwise the Java virtual machine invokes loadClass(N ) on L."
> >
> > [0] http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79441
> >
> >
> > > So this is definitely bug of DRLVM, which should be fixed mainly on VM
> > > side. And we may want to think how to avoid data duplication in VM and
> > > kernel classes on this matter...
> > >
> > > > > AFAIK, there is the bug: DRLVM does not record initiating class
> > loader of a
> > > > > class. (1) is just the consequence.
> > > > Not really. After H-1363 (aka BBC), j.l.ClassLoader records initiated
> > > > classes. There may be some holes in impl (e.g. for array classes), but
> >
> > > > kernel classes fulfill API contract in general.
> > > >
> > > > >
> > > > >
> > > > > On 10/9/06, Alexey Varlamov < alexey.v.varlamov@gmail.com >
wrote:
> > > > > >
> > > > > > Folks,
> > > > > >
> > > > > > Would you mind to spend some time looking at HARMONY-1688? Good
> > > > > > knowledge of classloading and security machinery is an advantage
> > :)
> > > > > >
> > > > > > In short, we face 2 issues in DRLVM:
> > > > > > 1) DRLVM itself is not aware of classes initiated (in contrast
to
> > > > > > defined ones) by a loader, and always delegates to Java classes
> > for
> > > > > > lookup (except bootstrap loader, of course). This is not really
> > queer
> > > > > > behaviour, but seems incompartible with most VMs. BTW, currently
> > this
> > > > > > affects implementation of jvmtiGetClassLoaderClasses(), which
I
> > > > > > believe has a bug - it returns defined classes only.
> > > > > > 2) j.s.AccessController of DRLVM treats system classes (i.e.
> > loaded by
> > > > > > bootstrap loader) equally with application classes while examining
> >
> > > > > > execution stack, while RI seems to be simply skipping them.
In
> > other
> > > > > > words, DRLVM would always perform ProtectionDomain.checkPermission
> > ()
> > > > > > with AllPermission for bootstrap classes, and RI will omit such
> > check
> > > > > > if no user classes on stack. This potentially may produce subtle
> > > > > > effects in security-exigent areas.
> > > > > >
> > > > > > Also, both can be considered from performance perspective,
> > probably
> > > > > > having somewhat negative impact.
> > > > > > What do you think, how will we resolve this?
> > > > > >
> > > > > > [0] http://issues.apache.org/jira/browse/HARMONY-1688
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > 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


Mime
View raw message