Modifying graph to include InvokeNode

Doug Simon doug.simon at
Wed Jul 17 09:16:55 PDT 2013

On Jul 17, 2013, at 4:13 PM, Christophe Dubach <christophe.dubach at> wrote:

> On 16/07/13 17:38, Doug Simon wrote:
>> On Jul 16, 2013, at 5:58 PM, Christophe Dubach <christophe.dubach at> wrote:
>>>> An invoke node (that doesn't get inlined) in method A that calls method B will result in a call in the generated code. During execution of B, something may happen to invalidate an assumption made when compiling A (e.g., class loading invalidating a class hierarchy speculation). This means A is now invalid and needs to be deoptimized upon return from B. In the current system, we rely on HotSpot's deoptimization infrastructure to continue execution at the return site of A in the interpreter. HotSpot only (currently) supports deoptimize-on-return for call sites that have the BCI of an invoke bytecode.
>>> Thank you for the clarification, I think I see the problem.
>>> Is there a way we could add a new invokeNode in the graph and then force it to get inlined straight-away?
>> This is essentially what we do with snippets which is the direction Chris was initially heading. The problem you can still not do anything (like allocating/expanding a data structure) that causes deoptimization in the transitively inlined methods calls.
>> -Doug
> Thanks I understand. This would would should move the problem a little further.
> What about the use of invokedynamic as suggested by Remi? Would this help and if so how?

I'll let Remi or Christian Thalinger address that question as I don't have any real experience with invokedynamic.


More information about the graal-dev mailing list