VirtualObjects at deoptimization points.
Deneau, Tom
tom.deneau at amd.com
Thu May 15 18:19:28 UTC 2014
I guess I would have thought these constants would already be in the bytecode
and so wouldn't have to be in the debuginfo. But maybe these are things that
the compiler deduced were constant and were not in the bytecode?
-- Tom
From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq
Sent: Thursday, May 15, 2014 12:30 PM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: RE: VirtualObjects at deoptimization points.
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<mailto: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<mailto:gilwooden at gmail.com>]
Sent: Thursday, May 15, 2014 1:29 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net<mailto: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