RFR: 8067247: Crash: assert(method_holder->data() == 0 ...) failed: a) MT-unsafe modification of inline cache

Christian Thalinger christian.thalinger at oracle.com
Fri Mar 25 01:28:40 UTC 2016


> On Mar 24, 2016, at 11:05 AM, Jamsheed C m <jamsheed.c.m at oracle.com> wrote:
> 
> Hi All,
> 
> Request for review,
> 
> bug url:  https://bugs.openjdk.java.net/browse/JDK-8067247
> 
> webrevs:
> fix:
>   jdk part:  http://cr.openjdk.java.net/~jcm/8067247/webrev.jdk.00/
> 
> newly added test case
> hotspot part:
>    http://cr.openjdk.java.net/~jcm/8067247/webrev.hs.00/
> under hs-comp/test
>    http://cr.openjdk.java.net/~jcm/8067247/webrev.hs_comp.00/
> 
> Unit Test: test/compiler/jsr292/misc/gc/MHInvokeTest.java
> Testing: JPRT with new test case, with fix, without fix
> 
> Problem Summary:  MH.invoke linksite take assistance of java code to get an adapter method. Here a new method holder class and a adapter method are created for a MT and lform instance is cached.
> Normally this cached lform get returned for a linksite request of same MT.  When these cached lform get collected(due to memory pressure),  a new class and method gets created for same MT(even though old method holder class and  adapter method are live).
> Fix Summary: Kept a strong reference to lform instance in adapter method holder class of  MT.

Wow!  You found the cause for his long-standing issue?  Nice.
+  if (method == NULL) { return; }
+  nmethod* nm = method->code();
+  if (nm == NULL) { return; }
+  if (nm->is_unloaded()) { return; }
Please put the return and } on separate lines.

> 
> Best Regards,
> Jamsheed
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160324/95d11f31/attachment.html>


More information about the hotspot-compiler-dev mailing list