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