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