assertion in ciTypeFlow OSR'ing in finally clause (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Feb 17 11:34:30 PST 2014

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(returnaddress->isreturnaddress()) 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(returnaddress->isreturnaddress(), "verify: wrong type"); ciTypeFlow.cpp:812 assert(address->isreturnaddress(), "bad return address"); ciTypeFlow.cpp:1758 assert(returnaddress->isreturnaddress(), "verify: wrong type"); ciMetadata.hpp:83 assert(isreturnaddress(), "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