harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Date Tue, 24 Oct 2006 07:49:15 GMT
Ok.
I've created *HARMONY-1945*<https://issues.apache.org/jira/browse/HARMONY-1945>.
You
can find tests here.

BR.
Pavel Afremov


On 10/23/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
>
> Pavel, I see no attachment.. ?
>
> On 10/23/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> >
> > Hi
> >
> >
> >
> > I've developed two "impossible" tests, which shows "fake" circularity
> > errors. One test is more simple and use SecurityManager. The other is a
> bit
> > more complex and uses custom ClassLoader. You can find them in
> attachment.
> >
> >
> >
> > Thanks.
> >
> > Pavel Afremov
> >
> >
> > On 10/17/06, Pavel Pervov <pmcfirst@gmail.com> wrote:
> > >
> > > The scenario I described earlier is impossible. Resolution of any
> class
> > > referenced in some other class is performed by class loader, which
> > > loaded
> > > that other class. So, no chance to load "A" and referencing class
> loader
> > > (UCL) with this UCL.
> > >
> > > Sorry for confusion.
> > >
> > > Regards,
> > >    Pavel.
> > >
> > > P.S. Still there are concerns why lazy resolution should be supported
> by
> > >
> > > JITs. But it is absolutely another story.
> > >
> > > On 10/17/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > > >
> > > > IMO we shall be between BEA and SUN: to work if both RI work, to
> fail
> > > if
> > > > both RI fail and discuss each test in details if only one RI passes.
> > > >
> > > > On 10/17/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> > > > >
> > > > > On Friday 13 October 2006 08:04 Alexey Varlamov wrote:
> > > > > > 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
> > > > > > DRLVM.
> > > > >
> > > > > I think it is different. URLClassLoader is system class which is
> > > loaded
> > > > by
> > > > > bootstrap, so no recursion happens for classes which it itself
> > > requires
> > > > to
> > > > > be
> > > > > loaded when it is being compiled.
> > > > >
> > > > > > 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.
> > > > >
> > > > > It is not endless but it is definitely more than 1 level deep. If
> > > user
> > > > > sets up
> > > > > his own class loaders, compiling them may trigger loading some of
> > > the
> > > > user
> > > > > classes which are in turn loaded by class loaders set up by user.
> > > Shall
> > > > we
> > > > > then throw "NoClassDefFoundError: Class loading recursion limit
> > > reached.
> > > > > Please rewrite your code"? :)
> > > > >
> > > > > --
> > > > > 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
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Mikhail Fursov
> > > >
> > > >
> > >
> > >
> >
>
>
> --
> Mikhail Fursov
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message