NullPointerException in HotSpotRuntime:lower when using Snippets
Mick Jordan
mick.jordan at oracle.com
Mon Jul 15 11:57:57 PDT 2013
On 7/15/13 11:38 AM, ATKIN-GRANVILLE Chris wrote:
> I can't say I've given much thought to it yet, but I will now. I've been looking at modifying bytecode using javassist/ASM to call instrumentation, but there's other issues with that (mainly being able to detect loops would be manual). If I used Maxine + VMA, would it be relatively easy to implement dynamic tracing /in a loop/ - and /only/ in a loop? This is the disadvantage of using tools as low-level as VMA - I've lost a lot of the semantic information that is available at compile time (in Graal I had does-the-operation-exist-inside-a-loop working in <5 mins).
>
>
That's an interesting requirement. There are other frameworks, e.g.,
DiSL <http://d3s.mff.cuni.cz/publications/download/Marek-aplas12.pdf>,
that allow regions of bytecode to identified for analysis. You are
correct that Maxine/VMA based on the T1X baseline compiler has no more
information than the original bytecode stream, so recovering loops
requires some work. In the simple callback model, the advice itself
cannot be limited to the loop, you have to detect the loop bytecodes and
only analyse the array accesses when you know you are in the loop.
Graal/VMA evidently makes this easier as more of the original source is
available explicitly the graph. However, it is a fact that Graal was not
designed as an analysis framework, and is somewhat lossy - for example
the kind of loop is not kept and some transformations,e.g.
canonicalization of the various IF forms happen before you can get
control. Nevertheless, it is a much more robust framework and graphs are
much preferable to bytecode streams. DiSL could be implemented on Graal,
no doubt, perhaps with some small extensions. E.g., the bytecode index
is not routinely available for an arbitrary node.
Mick
More information about the graal-dev
mailing list