Emitting Graal IR

Thomas Wuerthinger thomas.wuerthinger at oracle.com
Fri Apr 6 09:13:46 UTC 2018


The complexities of directly emitting IR graphs (and the associated debug informations for deoptimizations) were the main trigger for developing Truffle. Please find a detailed description of our partial evaluation approach and why we think it is superior to traditional code generation approaches in this paper "Practical Partial Evaluation for High-Performance Dynamic Language Runtimes": http://chrisseaton.com/rubytruffle/pldi17-truffle/pldi17-truffle.pdf

Cheers, thomas

> On 6 Apr 2018, at 11:03, Renzo Borgatti <reborgml at gmail.com> wrote:
> Hi,
> I have a language written in Java that generates bytecode dynamically via ASM library. I'm trying to understand feasibility/tradeoffs of emitting IR graphs or CFG block) instead of bytecode. Looking at how this is done in BytecodeParser.java (along with BciBlockMapping::iterateOverBytecodes() and FrameStateBuilder) it looks like it's possible. The question is if you'd consider this a possible approach and if you know of any project using Graal this way (apart from Graal subprojects internally). I'm aware of Truffle, but I'd rather go straight to IR graphs if that's an option. Any reason not to?
> Thanks
> Renzo

More information about the graal-dev mailing list