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