Debugging NPE during CanonicalizerPhase

[Andreas Woess]

Hi Stefan,

I've found the bug and I think I have a workaround for you until this is
fixed.
In ReturnNonLocalNode you have try {... throw new ReturnException ...}
catch (FrameSlotTypeException) {...}. Avoid this try-catch block around
any throw of a ControlFlowException. I suggest factoring out
"try-getObject-catch-shouldNotHappen" into a separate method -- you use
this pattern in several places.

- andreas

On 2013-08-07 22:29, Stefan Marr wrote:
> 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
>
>