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