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
