Debugging NPE during CanonicalizerPhase
Stefan Marr
java at stefan-marr.de
Wed Aug 7 13:29:31 PDT 2013
Hi Andreas,
Hi Thomas:
On 07 Aug 2013, at 19:05, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
> The -XX:+TraceDeoptimization output can also provide hints on what is wrong. Repeated deoptimizations could be caused by CompilerDirectives.transferToInterpreter() calls on wrong code paths or SlowPathExceptions being thrown without a follow-up node rewrite.
Thanks for the hint.
> On Aug 7, 2013, at 9:40 AM, Andreas Woess <andreas.woess at jku.at> wrote:
>
>> Hi Stefan,
>>
>> Unfortunately, those are the tricky ones to debug. I'll investigate.
>> What's the simplest test that where this happens?
The loop benchmark still seems to be a good example, or Fibonacci, both with a TruffleCompilationThreshold of 100.
An example trace looks like this:
./mx.sh --vm server vm -XX:+TraceDeoptimization -G:TruffleCompilationThreshold=100 -Xbootclasspath/a:../som/build/classes som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/Fibonacci.som
[...]
[truffle] optimized Method at 655c8b5b |Nodes 5 |Time 64( 24+40 )ms |Nodes 435/ 1417 |CodeSize 6717
Uncommon trap bci=118 pc=49942186, relative_pc=5866, method=executeGeneric
Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (@0x0000000102fa0eaa) thread=6403 reason=uninitialized|unresolved action=make_not_entrant unloaded_class_index=-1
Uncommon trap bci=118 pc=48081130, relative_pc=5866, method=executeGeneric
Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (@0x0000000102dda8ea) thread=6403 reason=uninitialized|unresolved action=make_not_entrant unloaded_class_index=-1
[truffle] optimized Method at 3593092b |Nodes 5 |Time 63( 24+39 )ms |Nodes 435/ 1417 |CodeSize 6717
[truffle] invalidated Method at 655c8b5b |Alive 65ms |Inv# 109 |Replace# 0
Uncommon trap bci=118 pc=45972650, relative_pc=5866, method=executeGeneric
Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (@0x0000000102bd7caa) thread=6403 reason=uninitialized|unresolved action=make_not_entrant unloaded_class_index=-1
[truffle] optimized Method at 655c8b5b |Nodes 5 |Time 63( 24+40 )ms |Nodes 435/ 1417 |CodeSize 6749
Uncommon trap bci=118 pc=45903818, relative_pc=5898, method=executeGeneric
Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (@0x0000000102bc6fca) thread=6403 reason=uninitialized|unresolved action=make_not_entrant unloaded_class_index=-1
Uncommon trap bci=118 pc=45972650, relative_pc=5866, method=executeGeneric
Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (@0x0000000102bd7caa) thread=6403 reason=uninitialized|unresolved action=make_not_entrant unloaded_class_index=-1
[truffle] invalidated Method at 3593092b |Alive 65ms |Inv# 81 |Replace# 0
[truffle] invalidated Method at 655c8b5b |Alive 1ms |Inv# 110 |Replace# 0
So, trying to parse this: I guess I leave something uninitialized somewhere, or initialize something in a way that it is not obvious to the compiler? (reason=uninitialized|unresolved)
Looking at what I would guess is most related (Method class and MessageNode class) I see Method.initializeFrame and remember that Thomas was mentioning something about better handling parameters/arguments.
What would be a good way to debug this?
From grep-ing through the code, it looks like 'Uncommon trap' is coming directly from HotSpot.
But I am not entirely sure how to read the code that looks like it is hocking up a callback back into Java.
Thanks
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
More information about the graal-dev
mailing list