SIGSEGV while Parse::optimize_inlining an invokedynamic (original) (raw)

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Sun Sep 18 09:41:37 PDT 2011

Hi,

i think i send this to the wrong list(hotspot-runtime-dev). Now posting it here:

Hi, while doing further investigations on my idea [0] 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 [1]. 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; [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] // Which is effective cause = o.getCause(); System.out.println(cause); Throwable newCause = new RuntimeException("NEW"); INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] // 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 [2].

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 28cf2aec4dd7 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?

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.

[0] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ [1] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash.jar [2] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/hs_err_pid7339.log

-- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

More information about the hotspot-compiler-dev mailing list