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