RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_, valid()) failed: obj is valid

Daniel D. Daugherty daniel.daugherty at oracle.com
Thu Jul 23 00:35:07 UTC 2015


On 7/22/15 10:20 AM, Coleen Phillimore wrote:
> Summary: Walk compile task for Method* to not deallocate, store 
> methods in methodHandle while compile task is being created

Wait... 'while compile task is being created'...
You're holding these handles while the compile task
is being removed... Am I confused here?


> I couldn't reproduce this or write a test with the exact timing needed 
> to get this crash, but this is what the stack trace and code 
> inspection tells me what happened.  Reran all redefinition and 
> internal tonga 'quick' tests on the change with no regression.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/

src/share/vm/compiler/compileBroker.hpp
     No comments.

src/share/vm/compiler/compileBroker.cpp
     Is there a reason to have save_method and save_hot_method
     defined all the way up at lines 671-672 instead of
     being defined and init'ed on lines 710-711?

     L708:   // Save method pointer across
         Typo: 'pointer' -> 'pointers'

     So the idea of this fix is that you're holding methodHandles for
     these method pointers while removing the task because removing
     the task can go to a safepoint. While we're at that safepoint,
     a RedefineClasses call can come along and try and access/use the
     method pointers. If we didn't have methodHandles on them, they
     could be freed by the time RedefineClasses tries to access/use
     them...

     Do I have this right? Ouch and nice find.

src/share/vm/runtime/thread.cpp
     No comments.


> bug link https://bugs.openjdk.java.net/browse/JDK-8082782
>
> Thanks,
> Coleen



More information about the hotspot-dev mailing list