RFR: 8262377: Parallel class resolution loses constant pool error [v4]

[Coleen Phillimore]

On Wed, 10 Mar 2021 05:43:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove complicated test in favor of Ioi's test, fix cause.
>
> src/hotspot/share/oops/constantPool.cpp line 561:
> 
>> 559:   // We also need to CAS to not overwrite an error from a racing thread.
>> 560: 
>> 561:   jbyte old_tag = Atomic::cmpxchg((jbyte*)this_cp->tag_addr_at(which),
> 
> So the theory of operation is: if all racing threads resolve the klass successfully then they will have obtained the same klass instance and so it doesn't matter which thread actually called Atomic::release_store(adr, k);
>  above most recently. One thread will manage to update the tag and all threads will return 'k'.
> If any thread encounters a resolution error there is a another CAS of the tag to ensure only one of them is first. If the error thread is first the others will see the UnresolvedClassInError and clear the klass from resolved_klasses() again.

Yes.

> src/hotspot/share/oops/constantPool.cpp line 587:
> 
>> 585: 
>> 586:   if (this_cp->tag_at(which).is_klass()) {
>> 587:     Klass* k = this_cp->resolved_klasses()->at(resolved_klass_index);
> 
> If this can't be encapsulated in a helper function please add a comment about checking the tag first.

Ok.  I'll add the comment and file an RFE to encapsulate this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2718