Uncommon trap in OptimizedCallTarget::executeHelper

Stefan Marr java at stefan-marr.de
Fri Jan 17 04:12:11 PST 2014


Hi Tom:

On 16 Jan 2014, at 19:27, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:

> On Jan 16, 2014, at 8:15 AM, Stefan Marr <java at stefan-marr.de> wrote:
> 
>> [truffle] optimized Method Vector>>#at::../som/Smalltalk//Vector.som:33 at 687080dc 726302d8 |Nodes      19 |Time     8(   6+3 )ms |Nodes   102/   83 |CodeSize 336
>> Uncommon trap   bci=11 pc=301889326, relative_pc=270, method=executeGeneric, speculation=0
>> Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (Graal: installedCodeName=HotSpotMethod<OptimizedCallTarget.executeHelper(PackedFrame, Arguments)>)  (@0x0000000111fe772e) thread=6403 reason=null_assert|unreached0 action=reinterpret unloaded_class_index=-1 speculation=0
>> [truffle] invalidated Method Vector>>#at::../som/Smalltalk//Vector.som:33 at 687080dc |Inv# 3161                                |Replace# 8
>> 
>> The first odd thing is that the method name is executeGeneric, but then the line after refers to executeHelper in OptimizedCallTarget.
> 
> The first message is the method and bci of an inlined method which is the actual trap point.  executeHelper is the root of the compilation.  The first message probably should be printing the class name in addition the method name.  You can get more detail from the VM itself using -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation.  This caused hotspot to dump an xml log of compiler related events.

Thanks, that gave indeed a little bit more information.
However, after moving around some code, and changing a few things here and there, I still get this:

./mx.sh --vm server vm -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -G:+TraceTruffleExpansion -G:+TraceTruffleExpansionSource -XX:+TraceDeoptimization -G:-TruffleBackgroundCompilation -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes:../som/libs/truffle.jar som.vm.Universe -cp ../som/Smalltalk:../som/Examples/Benchmarks/Richards ../som/Examples/Benchmarks/BenchmarkHarness.som WhileLoopVAt 20 10 1000

"""
[truffle] optimized Method Vector>>#at::../som/Smalltalk//Vector.som:33 at 4abdb505 260c80da |Nodes      19 |Time     6(   5+2   )ms |Nodes    75/   39 |CodeSize 176
Uncommon trap   bci=0 pc=40496624, relative_pc=144, method=executeHelper, speculation=0
Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (Graal: installedCodeName=HotSpotMethod<OptimizedCallTarget.executeHelper(PackedFrame, Arguments)>)  (@0x000000010269edf0) thread=6403 reason=null_assert|unreached0 action=reinterpret unloaded_class_index=-1 speculation=0
[truffle] invalidated Method Vector>>#at::../som/Smalltalk//Vector.som:33 at 4abdb505 |Inv# 285                                     |Replace# 8
"""

Were the log says:

"""
Uncommon trap   bci=0 pc=39901936, relative_pc=144, method=executeHelper, speculation=0
<uncommon_trap thread='6403' reason='null_assert|unreached0' action='reinterpret' speculation='0' compile_id='-1' compiler='Graal' level='1' count='141' state='null_assert|unreached0 recompiled' recompiles2='140' stamp='8.999'>
Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (Graal: installedCodeName=HotSpotMethod&lt;OptimizedCallTarget.executeHelper(PackedFrame, Arguments)&gt;)  (@0x000000010260daf0) thread=6403 reason=null_assert|unreached0 action=reinterpret unloaded_class_index=-1 speculation=0
<jvms bci='0' method='com/oracle/graal/truffle/OptimizedCallTarget executeHelper (Lcom/oracle/truffle/api/frame/PackedFrame;Lcom/oracle/truffle/api/Arguments;)Ljava/lang/Object;' bytes='19' count='8139' iicount='8139' throwouts='391' decompiles='141' null_assert|unreached0_traps='141' overflow_recompiles='140'/>
</uncommon_trap>
"""

I have no idea what’s going on here.
But, I somehow suspect Gilles might be interested in this one. At least, the keywords of his commits and this output seem to be related.
However, it could also be something completely else of course :-/

Beside those traps, are there any other means to track for instance code invalidation?
Not on this, but on one of the other benchmarks, I got issues with code getting invalidated, but I can’t obtain any information about the reason.
The exception caught in the Truffle code has no useful information attached to it.

Thanks
Stefan



-- 
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/





More information about the graal-dev mailing list