harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fedotov, Alexei A" <alexei.a.fedo...@intel.com>
Subject RE: [drlvm] Non-bug difference HARMONY-1688?
Date Tue, 10 Oct 2006 09:38:56 GMT
Egor,
You wrote,
> The root cause is somewhere beyond the JIT.

Have you agreed with Mikhail suggestion to fix
http://issues.apache.org/jira/browse/HARMONY-1688 on JIT side?


With best regards,
Alexei Fedotov,
Intel Middleware Products Division

>-----Original Message-----
>From: Alexey Varlamov [mailto:alexey.v.varlamov@gmail.com]
>Sent: Monday, October 09, 2006 4:16 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [drlvm] Non-bug difference HARMONY-1688?
>
>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