harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Date Fri, 13 Oct 2006 04:04:46 GMT
13.10.06, Gregory Shimansky<gshimansky@gmail.com> написал(а):
> On Thursday 12 October 2006 14:06 Mikhail Fursov wrote:
> > On 10/12/06, Pavel Pervov <pmcfirst@gmail.com> wrote:
> > > Yes, lazy (interpreter style) resolution will solve the problem - JIT
> > > will never ask to load classes while compiling.
> >
> > Here we have different vision. What do you think, is it possible to go into
> > the endless resursion with lazy resolution?
> AFAIK it is not a matter of endless recursion. It just the a matter of how VM
> class loader determines CCE condition. If a class loading requested for a
> class which is being loaded already somewhere up the stack, it is determined
> as a CCE. This method is very effective and works just fine, I think RI uses
> something similar. It doesn't require analyzing the whole classes tree and
> exception is thrown only on demand.
I'm curious, if we enable "controlled" recursion in classloading -
will it resolve this kind of issues completely? I'm pretty sure it
would resolve at least some scenarios - like the one Pavel described
for gc.Finalizers or a case of classloading initiated within
SecurityManager.checkPermission() which we also faced not once.
"Controlled" recursion here means counting depth of recursion and
allowing at least 1 recursive iteration. I've seen some tricks in
URLClassLoader which assume such ability, but they do not work with
For the pure user code scenario Pavel suggested above, there may be
some nuances leading to truly endless recursion, but still we need to
look at particular test first.


> --
> Gregory Shimansky, Intel Middleware Products 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
View raw message