assertion in ciTypeFlow OSR'ing in finally clause

[Vladimir Kozlov]

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.
>