Graal - first step
thomas.wuerthinger at oracle.com
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?
More information about the graal-dev