harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject [dlrvm] ClassCircularityError in recursive compilation (Was: Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Date Wed, 11 Oct 2006 12:15:58 GMT
(Branching from original thread as this is different problem than in the
root message.)

Mikhail,

The following scenario will fail:

1) JIT compiles some method and resolves some class "A" through user defined
class loader
2) user define class loader loads class "A" and triggers compilation of some
of its methods
3) this method happens to depend on class "A", and, thus, JIT resolves the
class "A" through the same class loader

Voila! We have the described situation.

Regards,
    Pavel.

On 10/11/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
>
> Pavel,
> Can you describe the problem with user's code only?
> Would BEA or SUN VM be able to run the test?
> I think we can create a separate discussion or JIRA for it.
>
> On 10/11/06, Pavel Pervov <pmcfirst@gmail.com> wrote:
> >
> > Michail,
> >
> > Generally speaking I can think of fully user code which produces exactly
> > the
> > same result.
> > So, workarounding this in one place (finalizers) just is not enough.
> >
> > Regards,
> >     Pavel.
> >
> > On 10/11/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > >
> > > On 10/11/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
> > > >
> > > > I believe the real root cause is running java code from
> > > > vm_hint_finalize().
> > > > A possible solution would be:
> > > >
> > > > - rewrite vm_hint_finalize() to just run 'notify' operation, without
> > > > calling any real java code
> > > > - handle reference queue in the finalizer thread instead of
> enqueuing
> > it
> > > > directly from vm_hint_finalize() thread
> > > >
> > >
> > > I support the idea to fix the finalization code. The requirement from
> > JIT
> > > to
> > > use lazy resolution everywhere is overkill in this case.
> > > Also the lazy resolution requires very significant changes in the
> > current
> > > Jitrino.OPT implementation and will make the static modes (-Xem:opt,
> > > -Xem:sever_static) unusable because of the performance degradation.
> > >
> > > --
> > > Mikhail Fursov
> > >
> > >
> >
> >
>
>
> --
> Mikhail Fursov
>
>

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