Emitting Graal IR
gilles.m.duboscq at oracle.com
Fri Apr 6 13:03:17 UTC 2018
The biggest technical issue with such an approach is that if you don't have some form of bytecode backing up the IR that you are generating, you can't use deoptimization (there is nothing to deoptimize to).
In order to run on HotSpot with Graal, deoptimization will be needed.
On 06/04/18 13:36, Renzo Borgatti wrote:
> Thanks Thomas for the reference I had a quick read.
> I was under the assumption that some form of PE (and other optimisation techniques) was happening on the IR independently from Truffle and there should be an advantage already just by emitting IR. I understand there are good reasons to use Truffle for a new language, but if the language already exists and emits semi-optimised bytecode (e.g. some types are inferred others generate warnings to invite type hinting), it seems relatively straightforward to change it to emit IR. I was under the impression that this would be already an advantage over classic HotSpot graphs. Sorry if I'm talking rubbish here, it's very possible I don't understand it completely.
>> On 6 Apr 2018, at 10:13, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
>> 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:
>>> 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?
More information about the graal-dev