Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of pmcfirst@gmail.com designates
 64.233.166.183 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type;
        b=A4PDSjZnBLnY1FgRmx9VQTVkJsBGoQujr2T+6G1yU7NMbY2siiaXmushpEgX+ijbTZAtuiC41TjpnFFgz6unjvktmeIvVAUSH+OXAThdLI55fsbFH8d7npQsfF/wTXpioMup8OculiEtdQ/YBk9MDdNSWS1gZm0T2KWfZlDdgiI=
Message-ID: <e0f125db0610110515t1f75e58ew979e49a8a5d853d6@mail.gmail.com>
Date: Wed, 11 Oct 2006 16:15:58 +0400
From: "Pavel Pervov" <pmcfirst@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: [dlrvm] ClassCircularityError in recursive compilation (Was: Re:
 [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2423_12431793.1160568958853"

------=_Part_2423_12431793.1160568958853
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_2423_12431793.1160568958853--