Method Fusion proposal

[Gilles Duboscq]

Hi Flavio,

Usually, the difficult part of this kind of transforms are the stacks ("framestates") that your are going to give to the VM along with the compiled code.

In principle they should represent stacks and states that are possible to reach through the bytecodes that are being compiled so that things like deoptimization can work.

In previous experimentation we concluded that HotSpot really doesn't like fake framestates.
Maybe some of these HotSpot limitations could be lifted with some C++ changes??

Overall getting FrameState nodes that will work will be your biggest challenge:
- what will be the bci of the FrameState for the introduced calls?
- what values will be on the stack if deoptimization occurs for while the new calls or the re-written calls are on the stack? can execution proceed correctly?

 Gilles

On 15/06/18 16:27, Flavio Brasil wrote:
> *Hi Graal developers,We’ve been exploring a new JIT optimization at Twitter
> that could significantly improve the efficiency of some of the high-level
> abstractions normally used in Scala. The project is at its early stage so
> we thought it’d be best to have your feedback on it sooner rather than
> later since you might be interested in collaborating on it.The initial
> design doc is available at http://tiny.cc/graal-method-fusion
> <http://tiny.cc/graal-method-fusion> and open for comments.Thank you,Flavio
> BrasilVM Team @ Twitter*
>