assertion in ciTypeFlow OSR'ing in finally clause
Vladimir Kozlov
vladimir.kozlov at oracle.com
Wed Feb 19 08:29:50 PST 2014
Yes, unfortunately Replay tool has problems with such classes and also Lambda methods. Essentially with everything which
is generated during execution.
Sometimes it will work if you remove such info from replay.log file when there is no direct dependency on it during
compilation.
Thanks,
Vladimir
On 2/19/14 7:47 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> 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
> java.lang.NoClassDefFoundError: sun/reflect/GeneratedConstructorAccessor4
> java.lang.NoClassDefFoundError: sun/reflect/GeneratedConstructorAccessor4
> Caused by: java.lang.ClassNotFoundException: sun.reflect.GeneratedConstructorAccessor4
> at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
> ...
>
> Best regards,
> Goetz.
>
> -----Original Message-----
> 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
>
> Hi Vladimir,
>
> 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.
>
> Best regards,
> Goetz.
>
> 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
> org/eclipse/jdt/internal/codeassist/InternalCompletionContext.class
> 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
> java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/codeassist/InternalCompletionContext
> java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/codeassist/InternalCompletionContext
> Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.codeassist.InternalCompletionContext
> at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>
> Failed on org/eclipse/jdt/internal/codeassist/InternalCompletionContext
>
>
>
> -----Original Message-----
> 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
> debug VM:
>
> -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid1234.log
>
> And it is better if you use latest sources from hs/hs-comp which also
> record/replay inlining.
>
>>
>> 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:
>> http://cr.openjdk.java.net/~goetz/bug-ciTypeFlow/ciTypeFlow_trace.txt
>> 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.
>
> thanks,
> Vladimir
>
>> But I didn't figure yet why it analyzes the block a third time with po #87.
>>
>> Best regards,
>> Goetz.
>>
>>
>>
>> -----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?
>>
>> 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.
>>>
More information about the hotspot-dev
mailing list