SIGSEGV while Parse::optimize_inlining an invokedynamic call.
christian.thalinger at oracle.com
Thu Sep 22 03:27:30 PDT 2011
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:
>>>> while doing further investigations on my idea  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 .
>>>> 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;
>>>> // Which is effective cause = o.getCause();
>>>> Throwable newCause = new RuntimeException("NEW");
>>>> INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V
>>>> // 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 .
>>>> 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
>>>> 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:
> I anyway have the intention to have a closer look at hotspot to create a
> prototype for my binary compatibility project i mentioned  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
>  http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
More information about the mlvm-dev