SIGSEGV while Parse::optimize_inlining an invokedynamic call.
christian.thalinger at oracle.com
Mon Sep 19 02:09:52 PDT 2011
[Moving hotspot-runtime-dev to Bcc]
On Sep 17, 2011, at 9:05 PM, Sebastian Sickelmann wrote:
> while doing further investigations on my idea  i observed a
> reproducable crash of the vm.
> It seems to me that it happens while the hotspot tries to inline (i
> think) a invokedynamic call.
> It happens only in my second Testcases (a case where an exception is
> thrown) so i tried
> to reduce it to a smaller amount of classes.
> I reduces the example of my idea to some core classes which i packed to .
> You can run the example starting the Main class. If you start it with
> -Xint no crash happens.
> I have packed it with the java-source or with disassembled classfile for
> the invokedynamic call.
> What is the Programm doing?
> Main starts TestNew2.testIt() 20000 times and prints out the thrown
> exception every time.
> TestNew2 is a generated class which does something like(just with out
> the local variable):
> NEW2 o = new NEW2();
> Throwable cause = INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable;
> // Which is effective cause = o.getCause();
> Throwable newCause = new RuntimeException("NEW");
> INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V
> // Which is effective o.initCause(newCause) which throws the
> exception that is catched by Main.
> The Binding is done via the Bootstrapper class.
> It looks up if the field "NEW2.cause" can be accessed by
> TestNew2 which isn't the case and binds the two calls to the methods
> NEW2.getCause and NEW2.initCause.
> I have checked it with
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode)
> i have put my hs_err_pid.log here .
> maybe b127 this is not the newest, but i didn't found a newer one. Maybe
> its the same problem as the porter-stemmer (don't interested me much
> till now) but -XX:-UseLoopPredicate (which i think should fix it) doen't
> solve it.
> I have cross-checked it also with my local openjdk8 builds.
> The builds are
> complete build of http://hg.openjdk.java.net/jdk8/jdk8 rev
> and even if i don't think it's a hotspot problem i checked it also
> against my openjdk8 with http://hg.openjdk.java.net/jdk8/tl/jdk/
> rev 75d763111eec
> I am not 100% sure if the error is on my side or if it is on the vm,
> maybe i have done something wrong with the invokedynamic. But i think it
> is inside hotspot because hotspot / interpreted-mode should work the
> same way, isn't it?
I can reproduce the bug and it is a VM issue (more precisely a C2 issue). Although the synopsis mentions deoptimization this is very likely a duplicate of:
7055941: JSR 292 method handle invocation causes excessive deoptimization for types not on boot class path
The the two classes involved in the is_subtype_of check are in different class loaders:
(dbx) fr 8
Current function is ciKlass::is_subtype_of
69 assert(is_loaded() && that->is_loaded(), "must be loaded");
(dbx) p this->print()
<ciInstanceKlass name=NEW2 loader=0xe614c000 loaded=true initialized=true finalized=false subklass=false size=16 flags=public,super super=java/lang/Object ident=715 PERM address=0x858e298>this->print() = (void)
(dbx) p that->print()
<ciInstanceKlass name=NEW2 loader=0x0 loaded=false ident=722 address=0x858e8b0>that->print() = (void)
Putting your test case on the boot class path makes it work:
$ java Main > /dev/null
$ java -Xbootclasspath/a:. Main > /dev/null
I'm looking into it.
> Please let me know if i can make further experiments that helps to
> isolate/solve this problem.
> -- Sebastian
> Sorry if the oss-patches.24.eu isn't as stable as it should be but this
> my only free webspace i have for this actually.
>  http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/
>  http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash.jar
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
More information about the hotspot-runtime-dev