assertion in ciTypeFlow OSR'ing in finally clause
goetz.lindenmaier at sap.com
Tue Feb 18 08:22:36 PST 2014
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.
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
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:
> 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,
> # 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
> 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,
More information about the hotspot-dev