RFR: JDK-8275704: Metaspace::contains() should be threadsafe

[David Holmes]

On Wed, 27 Oct 2021 13:07:25 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Metaspace::contains() is used in many places. It is not threadsafe since it walks the list of metaspace mappings, which can be altered concurrently. This is suspected to be the cause of JDK-8271124.
>> 
>> Currently, it does not lock, and adding a lock is not realistic either. It should work lockless.
>> 
>> This patch builds atop of https://bugs.openjdk.java.net/browse/JDK-8275582, which removed the old (pre JEP 387) technique of uncommitting metaspace memory. As a side effect, that patch changed the mapping list to an add-only structure. The only remaining place where it gets modified is in VirtualSpaceList::create_node(). Modifications are synchronized via lock. The only place where we walk the list locklessly is in Metaspace::contains(). This patch adds the appropriate memory barriers to those two places.
>> 
>> Tests:
>> - GHAs
>> - SAP nightlies (queued)
>
> src/hotspot/share/memory/metaspace/virtualSpaceList.cpp line 193:
> 
>> 191: bool VirtualSpaceList::contains(const MetaWord* p) const {
>> 192:   // Note: needs to work without locks.
>> 193:   const VirtualSpaceNode* vsn = Atomic::load_acquire(&_first_node);
> 
> I believe vsn->next() now also requires load_acquire semantics.

The internal nodes are already protected by the acquire/release semantics used for accessing `_first_node`, which is the only mutable field.

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

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