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