On the 0x1FE day of Apache Harmony Alexei A. Fedotov wrote: > 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?
not exactly Issue (1) in Harmony-1688 needs to be fixed on VM side, it falls into Circularity even on interpreter. Now I agree with Mikhail that JIT should *not crash* if method parameters are not resolved, throwing LinkageError correctly. This is moved to the separate JIRA: HARMONY-1802. That will be fixed on the JIT side. Does that answer your question? > > With best regards, > Alexei Fedotov, > Intel Middleware Products Division > > >-----Original Message----- > >From: Alexey Varlamov [mailto:[EMAIL PROTECTED] > >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 <[EMAIL PROTECTED]>: > >> 2006/10/9, Alexey Varlamov <[EMAIL PROTECTED]>: > >> > 2006/10/9, Pavel Pervov <[EMAIL PROTECTED]>: > >> > > 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 <[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: harmony-dev- > >[EMAIL PROTECTED] > >> > > > For additional commands, e-mail: harmony-dev- > >[EMAIL PROTECTED] > >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > > >--------------------------------------------------------------------- > >Terms of use : http://incubator.apache.org/harmony/mailing.html > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Egor Pasko, Intel Managed Runtime Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
