SIGSEGV while Parse::optimize_inlining an invokedynamic call.

[Sebastian Sickelmann]

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.thalinger at 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 at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>_______________________________________________
>mlvm-dev mailing list
>mlvm-dev at openjdk.java.net
>http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-- 
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.