VirtualObjects at deoptimization points.
Deneau, Tom
tom.deneau at amd.com
Thu May 15 17:04:02 UTC 2014
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<mailto: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<mailto: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<mailto: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> [mailto: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<mailto: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<mailto: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> [mailto: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<mailto: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<mailto: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
>> > > >> >
>> > > >> >
>> > > >
More information about the graal-dev
mailing list