On Sep 19, 2011, at 4:40 PM, Sebastian Sickelmann wrote: > Hi, > > i tried to simplify the TestNew2 class. But now it is to simple. > The crash is gone. I tried to make the process between Main and NEW2 > more complex, but this doesn't brings the crash back. > > i uploaded the new jar to > > http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash2.jar > > > Can you send me your suggested code for TestNew2 class as pseudo-code. I > will assemble and test it.
This is what I have now and it still reproduces the crash: // class version 51.0 (51) // access flags 0x1 public class TestNew2 { // compiled from: TestNew2.txt // debug info: // access flags 0x9 public static testIt()V L0 LINENUMBER 3 L0 NEW NEW2 DUP INVOKESPECIAL NEW2.<init> ()V DUP 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)] POP DUP NEW java/lang/RuntimeException DUP LDC "NEW" INVOKESPECIAL java/lang/RuntimeException.<init> (Ljava/lang/String;)V 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)] 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)] POP RETURN MAXSTACK = 5 MAXLOCALS = 0 } -- Christian > > The new actual disassembly looks like: > > // class version 51.0 (51) > // access flags 0x1 > public class TestNew2 { > > // compiled from: TestNew2.txt > // debug info: > > // access flags 0x9 > public static testIt()V > L0 > LINENUMBER 2 L0 > NEW NEW2 > DUP > INVOKESPECIAL NEW2.<init> ()V > NEW java/lang/RuntimeException > DUP > LDC "NEW" > INVOKESPECIAL java/lang/RuntimeException.<init> (Ljava/lang/String;)V > 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)] > RETURN > MAXSTACK = 4 > MAXLOCALS = 0 > } > > > -- Sebastian > > Am 19.09.2011 15:04, schrieb Sebastian Sickelmann: >> I can do this for you in a few hours.if it cannot wait you can clone my >> demo project mentioned in [0] and change the GEN class before starting the >> build.xml. The TestNew2.class and the Dissabled TestNew2.txt should be in >> the temp dir after running build.xml. >> >> Sorry for the previous mail. F*** german autocompletion of my smartphone. >> >> >> Sebastian Sickelmann<sebastian.sickelm...@gmx.de> schrieb: >> >>> I can so this for Sound in a gewesen hours. Info it cannot wait you can >>> clone my demo project mentioned in [0] and change the GEN class before >>> starting the build.xml. The TestNew2.class and the Dissabled TestNew2.txt >>> should bei in the temp dir after running build.xml. >>> ( >>> >>> Christian Thalinger<christian.thalin...@oracle.com> schrieb: >>> >>>> On Sep 19, 2011, at 11:09 AM, Christian Thalinger wrote: >>>> >>>>> [Moving hotspot-runtime-dev to Bcc] >>>>> >>>>> On Sep 17, 2011, at 9:05 PM, Sebastian Sickelmann wrote: >>>>> >>>>>> 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 format is the disassembled class file? How can I assemble it to a >>>> class file? I'd like to remove the println stuff. >>>> >>>> -- Christian >>>> >>>>>> 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? >>>>> 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 >>>>> Abort >>>>> $ java -Xbootclasspath/a:. Main> /dev/null >>>>> $ >>>>> >>>>> I'm looking into it. >>>>> >>>>> -- Christian >>>>> >>>>>> 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 >>>>>> _______________________________________________ >>>>>> mlvm-dev mailing list >>>>>> mlvm-dev@openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev@openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev@openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> -- >>> Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet. >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev@openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev