VirtualObjects at deoptimization points.
Deneau, Tom
tom.deneau at amd.com
Thu May 15 19:11:21 UTC 2014
ah, that makes sense...
> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com]
> Sent: Thursday, May 15, 2014 2:00 PM
> To: Deneau, Tom
> Cc: Gilles Duboscq; graal-dev at openjdk.java.net
> Subject: Re: VirtualObjects at deoptimization points.
>
> 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.c
> omputeAcc(VecmathNBodyDeoptTest.java:65) [bci: 20] #locals=12 #expr=0
> at
> com.oracle.graal.compiler.hsail.test.lambda.VecmathNBodyDeoptTest$Body.c
> omputeAcc(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