Modifying graph to include InvokeNode

Christophe Dubach christophe.dubach at ed.ac.uk
Tue Jul 16 07:41:20 PDT 2013


Dear Doug,

I'm currently supervising Chris with his work and have been following 
the discussion.

I am quite surprised that it is not possible to add an InvokeNode in a 
the graph of a method at runtime. When you say "We can only add static 
calls that are guaranteed to never be deoptimized" do you mean the 
callee or the caller? I am probably ignorant but I don't see what would 
be the difference between inserting an invokeNode to static method (not 
created dynamically) and an IntergerAdd node in the graph at runtime.

Anyway, thanks for the suggestion of doing bytecode instrumentation. Is 
it possible to do this directly with Graal or where you talking about 
patching the method at class load time? In our scenario, we want to 
limit our instrumentation to hot methods in order to further optimise 
them, therefore, we were aiming to do all this in the jit compiler.

Thanks,
Christophe.


  On 16/07/13 14:43, Doug Simon wrote:
> On Jul 16, 2013, at 3:27 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>
>> Oh, that may have been a silly thing to say, I know you can't "get" the BCI of a method call that doesn't exist in the bytecode. Even still, it seems like quite a large omission from graal to not be able to add static method calls into a graph…
> We can only add static calls that are guaranteed to never be deoptimized since there is no valid interpreter state to continue in for such invocations. I doubt that any bytecode compiler that relies on deoptimization could do any different…
>
> For your use case, bytecode instrumentation is what you want. Especially since you (seem to) need complete dynamic coverage of the code patterns you are interested in instrumenting.
>
> -Doug
>
>> On 16 Jul 2013, at 14:19, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk>
>> wrote:
>>
>>> Is it not possible to somehow "get" that BCI? It doesn't seem like adding static method calls should be impossible when graph transformations are possible...
>>>
>>> On 16 Jul 2013, at 14:14, Doug Simon <doug.simon at oracle.com>
>>> wrote:
>>>
>>>> This is almost certainly due to the fact that an invoke node must be associated with the BCI of a real invoke bytecode instruction. Otherwise, where would the interpreter resume if there is a deoptimization  during the invocation?
>>>>
>>>> On Jul 16, 2013, at 2:22 PM, ATKIN-GRANVILLE Chris <s1255753 at sms.ed.ac.uk> wrote:
>>>>
>>>>> Hi there,
>>>>>
>>>>> I'm trying to modify the graph to include an invoke node to a static function after certain node types. I'm modifying the graph at a high level before LoweringPhase.class (not a requirement, can change if required). However, I'm running into issues with JVM fatal errors. The code I have at the moment looks like this:
>>>>>
>>>>> public class MyPhase extends Phase {
>>>>> 	public void run(StructuredGraph graph) {
>>>>> 		for (Node node: graph.getNode()) {
>>>>>
>>>>> 			if ( node instanceof RandomFixedNode) {
>>>>> 				RandomFixedNode rfm = (RandomFixedNode) node;
>>>>> 				
>>>>> 				try {
>>>>> 					ResolvedJavaMethod method = getMethod(…);
>>>>> 					MethodCallTargetMode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static,
>>>>> 						method, new ValueNode[] {}, new HotSpotResolvedPrimitiveType(Kind.Void)));
>>>>>
>>>>> 					InvokeNode invoke = graph.add(new InvokeNode(callTarget, FrameState.UNKNOWN_BCI));
>>>>> 					invoke.setStateAfter(graph.add(new FrameState(FrameState.UNKNOWN_BCI)));
>>>>> 					graph.addAfterFixed(rfm, invoke);
>>>>> 				
>>>>> 				} catch (Exception e) {
>>>>> 					e.printStackTrace();
>>>>> 				}
>>>>> 			}
>>>>>
>>>>> 		}
>>>>> 	}
>>>>> }
>>>>>
>>>>> I'm pretty sure the problem is do with the BCIs and/or the FrameStates, but I don't know how to fix it. The error that I get is:
>>>>>
>>>>> Internal Error (/Volumes/Acme/Development/graal/src/share/vm/graal/graalCompilerToVM.cpp:44), pid=8466, tid=5379
>>>>> assert(hotspot_method != NULL && hotspot_method->is_a(HotSpotResolvedJavaMethod::klass())) failed: sanity
>>>>>
>>>>> Does anyone have any ideas?
>>>>>
>>>>> Thanks, Chris
>>>>>
>>>>> -- 
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
>>>>>
>>>>
>>>
>>>
>>> -- 
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>>
>>>
>>
>>
>> -- 
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



More information about the graal-dev mailing list