Request for reviews (S): 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP (original) (raw)

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Fri Sep 23 06:19:31 PDT 2011

Am 22.09.2011 12:23, schrieb Christian Thalinger:

http://cr.openjdk.java.net/~twisti/7092712/

7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP Reviewed-by: The problem is that ciEnv::getfakeinvokedynamicmethodimpl calls getunloadedmethod with java.lang.invoke.MethodHandle as the holder for unresolved call sites. Since the loader of j.l.i.MethodHandle is the boot class loader the resolving of e.g. signature classes is done with the boot class loader resulting in problems like: (dbx) p this->print() this->print() = (void) (dbx) p that->print() that->print() = (void) Later in the game a ciInstanceKlass lookup for NEW2 returns a ciInstanceKlass created during the signature resolving in getunloadedmethod with the boot class loader as loader resulting in the above situation. The fix is to always pass an accessor to getunloadedmethod and subsequently the ciMethod constructor. src/share/vm/ci/ciEnv.cpp src/share/vm/ci/ciEnv.hpp src/share/vm/ci/ciMethod.cpp src/share/vm/ci/ciMethod.hpp src/share/vm/ci/ciObjectFactory.cpp src/share/vm/ci/ciObjectFactory.hpp It fixed it for me on my Testcase with (jdk8). Thanks for that.

I can't review it formally (because i don't understand the fix in a complete manner) but should there be an automated test for this? Or is this not a common practice at hotspot-level?

Will there be a jdk7 backport?

-- Sebastian

More information about the hotspot-compiler-dev mailing list