On Sep 20, 2011, at 11:05 PM, Sebastian Sickelmann wrote: > Am 20.09.2011 13:19, schrieb Christian Thalinger: >> 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 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 >> It's not a duplicate of 7055941. I filed: >> >> 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with >> signature types not on BCP >> >> -- Christian > Is there a change to understand the details of this if i don't have > years of hotspot knowledge?
Maybe. Here is the webrev that also explains briefly why it failed: http://cr.openjdk.java.net/~twisti/7092712/ -- Christian > > I anyway have the intention to have a closer look at hotspot to create a > prototype for my binary compatibility project i mentioned [1] on my > blog. I actually solve this in an experiment with byte-code > transformation (to invokedynamic) in PreMain, but i think it can solved > in a better way inside the vm. > And if i think about solving this also for > Reflection/MethodHandles$Lookup i think i have to dive into hotspot in > some more depth. > > > -- Sebasitan > > [1] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ > [0] > _______________________________________________ > 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