Request for review (S) 6512830: Error: assert(tag_at(which).is_unresolved_klass(), "Corrupted constant,pool")
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed Mar 2 11:50:59 PST 2011
On 3/2/2011 11:25 AM, Coleen Phillimore wrote:
> Summary: Redefine classes copies the constant pool while the constant
> pool may be resolving strings or classes
>
> open webrev at http://cr.openjdk.java.net/~coleenp/6512830/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=6512830
src/share/vm/oops/constantPoolOop.cpp
So the race is that one thread is resolving something in
the CP we're copying. By fetching a copy of the CPSlot,
you're eliminating the data race. The copy you have is
either resolved or it's not resolved and now the call
to unresolved_klass_at_put() will see stable data...
Do I have this right? If so, then very nice catch!
src/share/vm/prims/jvmtiRedefineClasses.cpp
By adding JVM_CONSTANT_UnresolvedClass to this part of
the case switch, constantPoolOopDesc::copy_entry_to()
won't be called from RedefineClasses() so the change you
made in constantPoolOop.cpp for JVM_CONSTANT_UnresolvedClass
won't come into play for RedefineClasses(). Not a problem,
just an observation.
However that change will come into play for other callers...
And the change for JVM_CONSTANT_UnresolvedString will
come into play for RedefineClasses().
For RedefineClasses(), the classes need to be unresolved
at this stage of merging so your fix makes sure that even
a class that's in the middle of being resolved right now
stays unresolved.
Very nice! And thumbs up!
Dan
>
> Tested with jvmti tests.
>
> Thanks,
> Coleen
>
More information about the hotspot-runtime-dev
mailing list