assertion in ciTypeFlow OSR'ing in finally clause

Lindenmaier, Goetz goetz.lindenmaier at
Tue Feb 18 08:22:36 PST 2014

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:
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,

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at] 
Sent: Monday, February 17, 2014 8:35 PM
To: Lindenmaier, Goetz; 'hotspot-dev at'; ppc-aix-port-dev at
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?


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.

More information about the hotspot-dev mailing list