VirtualObjects at deoptimization points.

[Gilles Duboscq]

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(GraalInternalError.java:38)
>
>        at
> com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.getNodeForValueFromFrame(HSAILHotSpotLIRGenerator.java:182)
>
>        at
> com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createFrameState(HSAILHotSpotLIRGenerator.java:149)
>
>        at
> com.oracle.graal.hotspot.hsail.HSAILHotSpotLIRGenerator.createHostDeoptBranch(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
>
>