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

[Jiangli Zhou]

On Wed, 24 Jul 2024 20:25:23 GMT, Man Cao <manc at openjdk.org> wrote:

>> src/hotspot/share/tsan/tsanOopMapTable.hpp line 67:
>> 
>>> 65: 
>>> 66:   void release_weak_handle() const;
>>> 67:   oop object_no_keepalive() const;
>> 
>> I'm a bit unsure about the use of `oop` type vs `oopDesc*` type. Could we keep using `oopDesc*` type in `object_no_keepalive()`, `obj()`, `equals()` and `update_obj()`? E.g., whenever calling `_wh.peek()`, immediately cast the return value to a `oopDesc*`.
>> 
>> They are the same type in a release build, but different in a debug build. I vaguely recall that TsanOopSizeMap used `oop` in the JDK7/8 era, but switched to `oopDesc*` due to errors in debug build.
>
> Alternatively, it might be OK to declare TsanOopMapTableKey::_obj as an `oop` instead of `oopDesc*`. The main point is to avoid type conversions in various places.

Using `oop` for `TsanOopMapTableKey::_obj` is ok.

I also just built and tested with `fastdebug` JDK binary. I found a few places need `cast_from_oop<type>` conversions, e.g. in `InstanceKlass::initialize` when calling `SharedRuntime::tsan_acquire`. I've fixed those. I'll push my changes shortly. 

The tsan jtreg tests pass with `fastdebug` binary, except `RawRacyNativeLoopTest.java` and `NonRacyCasLoopTest.java`. That's the same with `slowdebug` binary. Those two tests fail with following assert. The failures should be unrelated to the tsan oop map. There is a separate internal bug that I created earlier to this specific issue.


#  Internal Error (/usr/local/google/home/jianglizhou/github/tsan-oopMap-weakhandle/src/hotspot/share/oops/accessBackend.cpp:224), pid=1986120, tid=1986364
#  assert(state == _thread_in_vm || state == _thread_in_Java || state == _thread_new) failed: Wrong thread state for accesses: 4

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

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