On Sep 19, 2011, at 4:40 PM, Sebastian Sickelmann wrote:
> Hi,
>
> i tried to simplify the TestNew2 class. But now it is to simple.
> The crash is gone. I tried to make the process between Main and NEW2
> more complex, but this doesn't brings the crash back.
>
> i uploaded the new jar to
>
> http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash2.jar
>
>
> Can you send me your suggested code for TestNew2 class as pseudo-code. I
> will assemble and test it.
This is what I have now and it still reproduces the crash:
// class version 51.0 (51)
// access flags 0x1
public class TestNew2 {
// compiled from: TestNew2.txt
// debug info:
// access flags 0x9
public static testIt()V
L0
LINENUMBER 3 L0
NEW NEW2
DUP
INVOKESPECIAL NEW2.<init> ()V
DUP
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)]
POP
DUP
NEW java/lang/RuntimeException
DUP
LDC "NEW"
INVOKESPECIAL java/lang/RuntimeException.<init> (Ljava/lang/String;)V
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)]
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)]
POP
RETURN
MAXSTACK = 5
MAXLOCALS = 0
}
-- Christian
>
> The new actual disassembly looks like:
>
> // class version 51.0 (51)
> // access flags 0x1
> public class TestNew2 {
>
> // compiled from: TestNew2.txt
> // debug info:
>
> // access flags 0x9
> public static testIt()V
> L0
> LINENUMBER 2 L0
> NEW NEW2
> DUP
> INVOKESPECIAL NEW2.<init> ()V
> NEW java/lang/RuntimeException
> DUP
> LDC "NEW"
> INVOKESPECIAL java/lang/RuntimeException.<init> (Ljava/lang/String;)V
> 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)]
> RETURN
> MAXSTACK = 4
> MAXLOCALS = 0
> }
>
>
> -- Sebastian
>
> Am 19.09.2011 15:04, schrieb Sebastian Sickelmann:
>> I can do this for you in a few hours.if 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 be in
>> the temp dir after running build.xml.
>>
>> Sorry for the previous mail. F*** german autocompletion of my smartphone.
>>
>>
>> Sebastian Sickelmann<sebastian.sickelm...@gmx.de> schrieb:
>>
>>> 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
>
> _______________________________________________
> 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
