assertion in ciTypeFlow OSR'ing in finally clause

[Lindenmaier, Goetz]

Hi Vladimir, 

No, I couldn't yet reproduce it in a small test case. Dacapo runs around 30min until
running into the problem.  I tried replay compilation, but I don't get that to work.
Is there some docu on that?

I don't think the visiting order is wrong, as the blocks are analyzed
twice successfully.  On a third try a block is marked 'irred' and has
no info about the return address.  This is the block with bytecodes 294-300.
I dumped the trace of the analysis:
 http://cr.openjdk.java.net/~goetz/bug-ciTypeFlow/ciTypeFlow_trace.txt
In this run, I removed all the assertions, so it runs until it aborts compilation.
There is some debug output where the first assertion would fire, in line 10524
of the trace file. Local 4 is bottom, so the assertion fires in
   ciTypeFlow::JsrSet::apply_control(): assert(... "verify: wrong type")

I think the assertion is just too strict if the control flow gets irreducible?
But I didn't figure yet why it analyzes the block a third time with po #87.

Best regards,
  Goetz.



-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Monday, February 17, 2014 8:35 PM
To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net
Subject: Re: assertion in ciTypeFlow OSR'ing in finally clause

Hi Goetz,

Do you have a simple test case? It would be nice to have it in VM regression tests as part of changes.
I would suggest to bail out from compilation immediately and leave asserts as they are. It looks like a corner case 
which I see for the first time.
But before that, can you check that there is no issue in RPO blocks ordering in ciTypeFlow?

Regards,
Vladimir

On 2/17/14 5:56 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I get an assertion in ciTypeFlow running the ppc port with DeotimizeALot.
>
> It tries to osr-compile a method at a bytecode in a finally clause.
>
> As far as I understand the assertion is too strict.
>
> The initial assertion is
>
>    #  Internal Error (/sapmnt/home1/d045726/oJ/raw-2-stage-hotspot/src/share/vm/ci/ciTypeFlow.cpp:218), pid=7287,
> tid=4398488891968
>
>    #  assert(return_address->is_return_address()) failed: verify: wrong type
>
> This happens because a block in the finally clause is analyzed while not
>
> both predecessor blocks have been looked at.  Thus the join of the
>
> slots that should contain the return address yields bottom, and the assertion
>
> fires.
>
> To get the dbg build passing, I have to remove 5 assertions:
>
> ciTypeFlow.cpp:195  assert(false, "verify: returning from invalid subroutine");
>
> ciTypeFlow.cpp:218  assert(return_address->is_return_address(), "verify: wrong type");
>
> ciTypeFlow.cpp:812  assert(address->is_return_address(), "bad return address");
>
> ciTypeFlow.cpp:1758 assert(return_address->is_return_address(), "verify: wrong type");
>
> ciMetadata.hpp:83  assert(is_return_address(), "bad cast");
>
> If I remove these, compilation is aborted a bit later with the message:
>
> "COMPILE SKIPPED: OSR starts with non-empty stack (not retryable)"
>
> I wonder whether I should fix this by adapting the assertions, or
>
> whether I should abort the compilation right away.
>
> I would appreciate some comments on this issue!
>
> Best regards,
>
>    Goetz.
>