harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm] Non-bug difference HARMONY-1688?
Date Tue, 10 Oct 2006 12:25:21 GMT
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: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
> 
> 

-- 
Egor Pasko, Intel Managed Runtime Division


---------------------------------------------------------------------
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