VirtualObjects at deoptimization points.
Doug Simon
doug.simon at oracle.com
Thu May 15 18:59:30 UTC 2014
This is almost certainly because the deopt restart point is after the bytecode that loads the constant(s).
-Doug
On May 15, 2014, at 8:19 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
> 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