RFR: 8262377: Parallel class resolution loses constant pool error [v4]
David Holmes
dholmes at openjdk.java.net
Wed Mar 10 06:26:09 UTC 2021
On Fri, 5 Mar 2021 12:52:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> src/hotspot/share/oops/constantPool.cpp line 555:
>>
>>> 553:
>>> 554: Klass** adr = this_cp->resolved_klasses()->adr_at(resolved_klass_index);
>>> 555: Atomic::release_store(adr, k);
>>
>> If we are racing then isn't it the case that we may not have an entry in resolved_klasses()?
>
> The order is: add the klass to resolved_klasses() and then set the tag. We need to check the tag in order to see whether the klass is correct or not. This is the way it worked before resolved_klasses() was added, but there were a couple of shortcuts to just check the klass != NULL. With the race to set UnresolvedClassInError, we need to check the tag first again, because the klass is set to null if the unresolved class has won the race.
Oh sorry - this is the code that sets the klass in the resolved_klasses().
I see now that we must always check the tag before using the value from resolved_klasses().
-------------
PR: https://git.openjdk.java.net/jdk/pull/2718
More information about the hotspot-dev
mailing list