assertion in ciTypeFlow OSR'ing in finally clause
goetz.lindenmaier at sap.com
Wed Feb 19 07:47:49 PST 2014
I found out that putting the classes on the bootclasspath helps.
But then it stops at classes generated by reflection:it stops at classes generated by reflection:
Resolving klass sun/reflect/Reflection at 247
Resolving klass sun/reflect/MagicAccessorImpl at 3
Caused by: java.lang.ClassNotFoundException: sun.reflect.GeneratedConstructorAccessor4
From: Lindenmaier, Goetz
Sent: Mittwoch, 19. Februar 2014 10:56
To: 'Vladimir Kozlov'; hotspot-dev at openjdk.java.net
Cc: ppc-aix-port-dev at openjdk.java.net
Subject: RE: assertion in ciTypeFlow OSR'ing in finally clause
Thanks for the short docu ;). That's just what I already tried,
along with some Replay flags handling initialization errors.
I made sure that I use consistently hs-comp. But that does not help.
It does not find the java classes.
I figured the benchmark runner only loads the benchmarks from
zip files in the dacapo .jar. So I added that directly, but that does
not help either (see below).
Probably replay only works with Java programs where all files
are directly in a jar file.
test/dacapo-2> dbg-ppc_vm/bin/jar -tf /usr/work/d045726/tmp/test/dacapo-2/data/eclipse/plugins/org.eclipse.jdt.core_3.1.2.jar | grep InternalCompletionContext
test/dacapo-2> dbg-ppc_vm/bin/java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid17515.log -XX:-UseSIGTRAP -XX:+DeoptimizeALot -jar /sapmnt/home/d045726/sapjvm_tools/benchmarks/dacapo/dacapo-2006-10-MR2.jar -cp /usr/work/d045726/tmp/test/dacapo-2/data/eclipse/plugins/org.eclipse.jdt.core_3.1.2.jar eclipse
Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.codeassist.InternalCompletionContext
at java.security.AccessController.doPrivileged(Native Method)
Failed on org/eclipse/jdt/internal/codeassist/InternalCompletionContext
From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
Sent: Dienstag, 18. Februar 2014 19:15
To: hotspot-dev at openjdk.java.net
Cc: ppc-aix-port-dev at openjdk.java.net
Subject: Re: assertion in ciTypeFlow OSR'ing in finally clause
On 2/18/14 8:22 AM, Lindenmaier, Goetz wrote:
> 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?
No docu, as usual :)
You add next flags to your command line you used to run app and run with
And it is better if you use latest sources from hs/hs-comp which also
> 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 will look on it later.
> I think the assertion is just too strict if the control flow gets irreducible?
I would like to keep the assert. We need to get full understanding about
what happened before we consider removing it. And we do handle
irreducible code for long time already.
> 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 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?
> 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