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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
