Modifying graph to include InvokeNode

[Christophe Dubach]

On 16/07/13 17:38, Doug Simon wrote:
> On Jul 16, 2013, at 5:58 PM, Christophe Dubach <christophe.dubach at ed.ac.uk> 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?

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.