You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexey Varlamov <al...@gmail.com> on 2006/10/09 12:16:33 UTC
[drlvm] Non-bug difference HARMONY-1688?
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
Re: [drlvm] Non-bug difference HARMONY-1688?
Posted by Alexey Varlamov <al...@gmail.com>.
2006/10/13, Eugene Ostrovsky <eu...@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
Re: [drlvm] Non-bug difference HARMONY-1688?
Posted by Eugene Ostrovsky <eu...@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..).
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.
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
>
>
Re: [drlvm] Non-bug difference HARMONY-1688?
Posted by Alexey Varlamov <al...@gmail.com>.
2006/10/9, Alexey Varlamov <al...@gmail.com>:
> 2006/10/9, Alexey Varlamov <al...@gmail.com>:
> > 2006/10/9, Pavel Pervov <pm...@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 <al...@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
Re: [drlvm] Non-bug difference HARMONY-1688?
Posted by Alexey Varlamov <al...@gmail.com>.
2006/10/9, Alexey Varlamov <al...@gmail.com>:
> 2006/10/9, Pavel Pervov <pm...@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."
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 <al...@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
Re: [drlvm] Non-bug difference HARMONY-1688?
Posted by Alexey Varlamov <al...@gmail.com>.
2006/10/9, Pavel Pervov <pm...@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.
> 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 <al...@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
Re: [drlvm] Non-bug difference HARMONY-1688?
Posted by Pavel Pervov <pm...@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).
AFAIK, there is the bug: DRLVM does not record initiating class loader of a
class. (1) is just the consequence.
On 10/9/06, Alexey Varlamov <al...@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
>
>