RFR (XS): JDK-6563994 - assert(wf.check_method_context(ctxk, m), "proper context") failed

[Christian Thalinger]

As Tom states in the bug report there is no easy way to fix this comprehensively.  The fix you’re proposing is a bandaid fix and don’t really like it.  That said, I can't think of a better way so I’m ok with the fix.

On May 19, 2014, at 8:42 AM, S. Bharadwaj Yadavalli <bharadwaj.yadavalli at oracle.com> wrote:

> I would like to get reviews for a small fix for the occasional nightly failures reported in https://bugs.openjdk.java.net/browse/JDK-6563994
> 
> The assertion is observed to be triggered while looking up for a monomorphic call target. It happens in a rare situation, where the method holder class is redefined at safepoints *after* resolution of the target method's class (in find_monomorphic_target() - src/share/vm/ci/ciMethod.cpp:694) but *before* the call of find_unique_concrete_method() - src/share/vm/ci/ciMethod.cpp:733). This change returns NULL for a such a redefined method which would be marked as old, indicating that candidate call target may not be inlined, since all we have is a pointer to an old method that has been redefined. The subsequent assertion of check_method_context for old methods is not applicable and hence not done for such methods.
> 
> Testing:
> 
> Without the fix: Was able to trigger the assertion upon running the test nsk.jvmti.RetransformClasses.retransform001 a few hundred times.
> 
> With the fix: Was able to run the test for over 3000 iterations continuously for more than 3 days without triggering the assertion.
> 
> Ran JPRT tests successfully
> 
> webrev: http://cr.openjdk.java.net/~bharadwaj/6563994/webrev_0/
> bug: https://bugs.openjdk.java.net/browse/JDK-6563994
> 
> Thanks,
> 
> Bharadwaj