VirtualObjects at deoptimization points.

Thu May 15 17:30:05 UTC 2014

Well there must be some local that contain those constant, for example the
delT1 argument of computeAcc.

When a value is know to be constant, the constant is directly embedded in
the debug info.

Maybe I didn't understand your question?

-Gilles
On 15 May 2014 19:04, "Deneau, Tom" <tom.deneau at amd.com> wrote:

>  Gilles --
>
>
>
> Yes this looks good.
>
> One question:  I noticed the infopoint where we are deopting in the new
> test does indeed use a virtual object and I see that the fields of the
> vobject are mapped to registers.
>
>
>
> But what is the purpose of those float constants being in the frame.  I
> see they are marked in graal as PrimitiveConstants but why would constants
> even need to be stored in the locals in the ByteCodeFrame?
>
>
>
> -- Tom
>
>
>
>   4386[<infopoint>] registerMap[ r40 r42 r43]
> com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.computeAcc(VecmathNBodyDeoptTest.java:65)
> [bci: 20] #locals=12 #expr=0
>
>   at
> com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.computeAcc(VecmathNBodyDeoptTest.java:65)
> [bci: 20]
>
>             |0     |1  |2                      |3
> |4                                         |5     |6     |7     |8  |9
> |10  |11
>
>    locals:  |d3|a  |-  |float[1.0|0x3f800000]  |float[0.005|0x3ba3d70a]
> |vobject:Vector3f:0{x=s7|f,y=s6|f,z=s5|f}  |d2|a  |s1|i  |s8|i  |-  |-
> |-   |-
>
> at
> com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest.lambda$runTest$37(VecmathNBodyDeoptTest.java:109)
> [bci: 22]
>
>             |0  |1     |2     |3     |4  |5
>
>    locals:  |-  |s0|i  |d3|a  |d0|a  |-  |-
>
>
>
>
>
> *From:* Gilles Duboscq [mailto:gilwooden at gmail.com]
> *Sent:* Thursday, May 15, 2014 1:29 AM
> *To:* Deneau, Tom
> *Cc:* graal-dev at openjdk.java.net
> *Subject:* Re: VirtualObjects at deoptimization points.
>
>
>
> I pushed something which passed the existing tests as well as your new
> test:
>
> http://hg.openjdk.java.net/graal/graal/rev/2208a130d636
>
> -Gilles
>
> Ok, thanks, I will use that.
>
> -Gilles
>
> On Wed, May 14, 2014 at 1:11 AM, Tom Deneau <tom.deneau at amd.com> wrote:
> > Gilles --
> >
> > You can try applying the attached patch to create a new test uses virtual
> > objects and does force a deopt.
> > When I tried this test with your patch, I did not get the correct results
> > but I didn't try to trace down whether it was due to anything with
> > virtual objects or not.
> >
> > -- Tom
> >
> >> -----Original Message-----
> >> From: Deneau, Tom
> >> Sent: Tuesday, May 13, 2014 5:59 PM
> >> To: Deneau, Tom; Gilles Duboscq
> >> Cc: graal-dev at openjdk.java.net
> >> Subject: RE: VirtualObjects at deoptimization points.
> >>
> >> Gilles --
> >>
> >> I noticed you had a link to a patch, I applied your patch and the one
> >> test mentioned below did not get an error at prepareHostGraph time as it
> >> usually did.
> >>
> >> I should add that while this test failed in prepareHostGraph, trying to
> >> handle a Virtual Object, this test doesn't actually deopt so it doesn't
> >> really test whether the virtual object can be handled correctly in the
> >> face of deopt.
> >>
> >> I can try to modify it so that it does deopt.
> >>
> >> -- Tom
> >>
> >>
> >> > -----Original Message-----
> >> > From: Deneau, Tom
> >> > Sent: Tuesday, May 13, 2014 5:53 PM
> >> > To: 'Gilles Duboscq'
> >> > Cc: graal-dev at openjdk.java.net
> >> > Subject: RE: VirtualObjects at deoptimization points.
> >> >
> >> > Gilles --
> >> >
> >> > Sorry for the delay in responding...
> >> > There is one test checked in trunk that currently fails because of
> >> > lack of VirtualObjectsInDeopt support.
> >> >
> >> > The test is
> >> > com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyTest
> >> > It is currently disabled from running by the following
> >> > (canHandleDeoptVirtualObjects() returns false) but you can comment
> >> > that out to make it run.
> >> >
> >> >     @Override
> >> >     protected boolean supportsRequiredCapabilities() {
> >> >         return (canHandleDeoptVirtualObjects());
> >> >     }
> >> >
> >> > I was going to say it should pass if -XX:-UseHSAILDeoptimization  is
> >> > on the command line but I see there is a bug in that it still tries to
> >> > create the host graph even if UseHSAILDeoptimization  is false.  This
> >> > logic can be fixed in HSAILHotSpotBackend.java by this little patch.
> >> >
> >> > ---
> >> >
> >> a/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai
> >> > l/HSAILHotSpotBackend.java  Tue May 13 15:38:56 2014 -0500
> >> > +++
> >> >
> >> b/graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsai
> >> > l/HSAILHotSpotBackend.java  Tue May 13 17:49:29 2014 -0500
> >> > @@ -924,7 +924,9 @@
> >> >
> >> >          ExternalCompilationResult compilationResult =
> >> > (ExternalCompilationResult) crb.compilationResult;
> >> >          HSAILHotSpotLIRGenerationResult lirGenRes =
> >> > ((HSAILCompilationResultBuilder) crb).lirGenRes;
> >> > -        compilationResult.setHostGraph(prepareHostGraph(method,
> >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs));
> >> > +        if (useHSAILDeoptimization) {
> >> > +            compilationResult.setHostGraph(prepareHostGraph(method,
> >> > lirGenRes.getDeopts(), getProviders(), config, numSRegs, numDRegs));
> >> > +        }
> >> >      }
> >> >
> >> > -- Tom
> >> >
> >> >
> >> > > -----Original Message-----
> >> > > From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of
> >> > > Gilles Duboscq
> >> > > Sent: Sunday, May 04, 2014 12:17 PM
> >> > > To: Deneau, Tom
> >> > > Cc: graal-dev at openjdk.java.net
> >> > > Subject: Re: VirtualObjects at deoptimization points.
> >> > >
> >> > > Hello,
> >> > >
> >> > > I currently have a prototype [1] that i would like to test. Before
> >> > > creating my own tests, i was wondering if you already have tests for
> >> > > this or if you know of tests that have escaping objects?
> >> > >
> >> > > -Gilles
> >> > >
> >> > > [1] http://cr.openjdk.java.net/~gdub/HSAILVirtualObjectDeopt.patch
> >> > >
> >> > > On Fri, May 2, 2014 at 7:21 PM, Tom Deneau <tom.deneau at amd.com>
> >> wrote:
> >> > > > Hi Gilles --
> >> > > >
> >> > > > Could I get an update on the support for VirtualObjects in the
> >> > > > host
> >> > > deopt trampoline code?
> >> > > >
> >> > > > -- Tom D.
> >> > > >
> >> > > >> -----Original Message-----
> >> > > >> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf
> >> > > >> Of Gilles Duboscq
> >> > > >> Sent: Thursday, April 03, 2014 5:04 AM
> >> > > >> To: Deneau, Tom
> >> > > >> Cc: graal-dev at openjdk.java.net
> >> > > >> Subject: Re: VirtualObjects at deoptimization points.
> >> > > >>
> >> > > >> Hello Tom,
> >> > > >>
> >> > > >> The reason I delayed the implementation of VirtualObjects is that
> >> > we
> >> > > >> have to reverse the process that transforms VirtualObjectNodes
> >> > > >> into VirtualObjects (that's in
> >> > > >> com.oracle.graal.compiler.gen.DebugInfoBuilder.build(FrameState,
> >> > > >> LabelRef)).
> >> > > >> It shouldn't be so complicated to add this support. I'll give it
> >> > > >> a
> >> > > try.
> >> > > >>
> >> > > >> -Gilles
> >> > > >>
> >> > > >> On Tue, Apr 1, 2014 at 1:07 AM, Tom Deneau <tom.deneau at amd.com>
> >> > > wrote:
> >> > > >> > Gilles --
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> > I noticed in one of our java8 lambda tests (not yet pushed to
> >> > > >> > trunk) we had some object allocation that was eliminated by
> >> > escape
> >> > > analysis.
> >> > > >> > But when we try to run this with the trunk now, we get
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> > com.oracle.graal.graph.GraalInternalError: unimplemented
> >> > > >> >
> >> > > >> >        at
> >> > > >> >
> >> > com.oracle.graal.graph.GraalInternalError.unimplemented(GraalIntern
> >> > > >> > alE
> >> > > >> > rror.java:38)
> >> > > >> >
> >> > > >> >        at
> >> > > >> >
> >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForV
> >> > > >> > alu
> >> > > >> > eFromFrame(HSAILHotSpotLIRGenerator.java:182)
> >> > > >> >
> >> > > >> >        at
> >> > > >> >
> >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrame
> >> > > >> > Sta
> >> > > >> > te(HSAILHotSpotLIRGenerator.java:149)
> >> > > >> >
> >> > > >> >        at
> >> > > >> >
> >> > com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostD
> >> > > >> > eop
> >> > > >> > tBranch(HSAILHotSpotLIRGenerator.java:140)
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> > where the line 182 in getNodeForValueFromFrame has
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> >         } else if (localValue instanceof VirtualObject) {
> >> > > >> >
> >> > > >> >             throw GraalInternalError.unimplemented();
> >> > > >> >
> >> > > >> >         }
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> > What would we need to do to support VirtualObjects at our
> >> > > >> > deoptimization infopoints?
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> > (We also don't support stack slots yet, but I think I
> >> > > >> > understand what is needed to support those).
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> > -- Tom
> >> > > >> >
> >> > > >> >
> >> > > >
>