RFR: Reimplement TsanOopMap support using WeakHandle and ResizeableResourceHashtable [v11]

[Jiangli Zhou]

On Sat, 27 Jul 2024 02:52:36 GMT, Man Cao <manc at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Use cast_from_oop<T> in various places when coverting oop to different types.
>>   - Change TsanOopMapTableKey::_obj to 'oop'.
>>   - Change TsanOopMapTableKey::equals to just do `lhs._obj == rhs._obj`.
>
> src/hotspot/share/tsan/tsanOopMapTable.cpp line 153:
> 
>> 151:         }
>> 152: 
>> 153:         entry.update_obj();
> 
> (Just a comment, no action required.)
> It is a bit unusual to mutate the key object of a hash table during iteration, as it could mess up key's hash value. Then subsequent `add`, `contains` operations may not find this existing key. Old `TsanOopSizeMap` implementation avoids this problem by creating a new hash table and add all remaining entries there.
> 
> However, it is safe here because `TsanOopMapTable` uses `identity_hash()`, so the hash value won't change. This also means enabling TSAN will invoke `identity_hash()` on all Java objects, which may have other side effects, but is probably OK.

It's safe because the entry still points to the same object, so it would not affect the key's hash value. This occurs during a STW GC pause, and access to the table from other concurrent worker threads is protected from the TsanOopMap_lock.

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

PR Review Comment: https://git.openjdk.org/tsan/pull/19#discussion_r1695720619