Debugging NPE during CanonicalizerPhase

[Thomas Wuerthinger]

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.

- thomas

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?
> 
> - andreas
> 
> On 07.08.2013 16:07, Stefan Marr wrote:
>> Hi Andreas:
>> 
>> On 07 Aug 2013, at 13:26, Andreas Woess <andreas.woess at jku.at> wrote:
>> 
>>> You have this code in ContextualNode:
>>>>         FrameSlot blockSelfSlot =
>>>> ctx.getFrameDescriptor().findFrameSlot("self");
>>>> 
>>> findFrameSlot will probably never return null here, but the compiler
>>> cannot know this and creates one branch where the frameSlot is null and
>>> one where it isn't -- in both branches it would call getObject. So a
>>> simple workaround would be to explicitly check for a (non-)null result here.
>>> 
>>> In any case, you should avoid findFrameSlot in compiled code and try to
>>> resolve frame slots at compile time, if possible. Or, at least
>>> specialize the access node after resolving the frame slot. In all
>>> likelihood, the frame slot will be the same every time.
>> Thanks! That was on the spot.
>> I already made sure that I didn't use findFrameSlot in the non-local returns, but I missed this one.
>> 
>> A one-line fix :)
>> https://github.com/smarr/TruffleSOM/commit/2bb714220bdca36dc2166bc240ca7dfb957364cb
>> 
>> Now it runs the benchmarks to completion :) nice. Thanks a lot!
>> 
>> I guess, now it is time for me to investigate how to specialize nodes.
>> 
>> A question that might be related to that: I noticed that methods have been repeatedly optimized and then invalidated.
>> And by repeatedly I am talking about thousands of times, I actually had to bump up the compilation threshold to make the benchmarks complete in a reasonable amount of time. Any idea what that could be indicating? Typically the benchmarks with such behavior are rather tight loops, recursion, fibonacci etc.
>> 
>> Thanks
>> Stefan
>> 
>> Example output:
>> 
>> [truffle] optimized Method at 346ff652                                    |Nodes       4 |Time    46(  10+36  )ms |Nodes   347/ 1135 |CodeSize 4886
>> [truffle] invalidated Method at 346ff652                                  |Alive     1ms |Inv# 1101                                     |Replace# 0
>> [truffle] optimized Method at 346ff652                                    |Nodes       4 |Time    61(  15+46  )ms |Nodes   347/ 1135 |CodeSize 4886
>> [truffle] invalidated Method at 346ff652                                  |Alive     0ms |Inv# 1102                                     |Replace# 0
>> [truffle] optimized Method at 346ff652                                    |Nodes       4 |Time    45(  11+35  )ms |Nodes   347/ 1135 |CodeSize 4886
>> [truffle] invalidated Method at 346ff652                                  |Alive     0ms |Inv# 1103                                     |Replace# 0
>> 
>> 
>