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