Graal - first step

Thomas Wuerthinger thomas.wuerthinger at
Tue Apr 3 07:57:50 PDT 2012

On 03.04.2012 12:10, Rémi Forax wrote:
> On 04/02/2012 12:10 PM, Douglas Simon wrote:
>> Hi Remi,
>> On Mar 30, 2012, at 7:13 PM, Rémi Forax wrote:
>>> Hi guys,
>>> I've played a little with Graal and I've some questions (a lot in 
>>> fact but I will send several messages :)
>> We're ready for your questions - fire away ;-)
> I was exploring the idea to replace the bytecode backeend of a runtime 
> like by example JRuby
> to construct a graph of graal's node.
> So please correct me if I'm wrong but I think it's not possible currently
> or possible in a very restricted way because each method need to be 
> have a bytecode attached.
> By example, a deoptimize node will call a code in Hotspot that will 
> trigger the interpreter
> so each method need a bytecode view.
Yes. HotSpot forces us to always deoptimize to a valid bytecode 
position. We are currently working on a new abstraction layer on top of 
Graal that will remove this constraint.
> Another related problem is that there is currently no node that does 
> profiling so
> I can't generate a graph of nodes with profile information that I will 
> be able to extract
> using Graal interface with Hotspot.
It is possible to generate a node that will lower itself to a store/load 
to an object that is pointing to the profiling data. The Graal snippet 
mechanism would allow to specify the lowering in Java code (like we do 
with arraycopy intrinsification, see ArrayCopySnippets class). What kind 
of general-purpose interface would you suggest for weaving profiling 
code into the Graal IR?

- thomas

More information about the graal-dev mailing list