SIGSEGV while Parse::optimize_inlining an invokedynamic call.

[Sebastian Sickelmann]

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