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. 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
