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

[Jiangli Zhou]

On Thu, 25 Jul 2024 01:26:14 GMT, Man Cao <manc at openjdk.org> wrote:

>> `oopDesc*` is different from `oop` in a fastdebug build, when `CHECK_UNHANDLED_OOPS` is defined.
>
> See the `oop` class definition [here](https://github.com/openjdk/jdk/blob/0898ab7f7496689e5de52a5dc4530ca21def1fca/src/hotspot/share/oops/oopsHierarchy.hpp#L53-L115). Note that `CHECK_UNHANDLED_OOPS` is only enabled in [fastdebug](https://github.com/openjdk/jdk/blob/0898ab7f7496689e5de52a5dc4530ca21def1fca/make/hotspot/lib/JvmFlags.gmk#L77-L81), not slowdebug.
> As said in the other comment,  we could declare `TsanOopMapTableKey::_obj` as an `oop`, but make sure to test with fastdebug build.

I just reread your earlier suggestion more closely. 

> is it better to do oopDesc* obj = _wh.peek()?

WeakHandle only defines `peek()` with `oop` as return type (see `inline oop peek() const;`). With `CHECK_UNHANDLED_OOPS`, the implicit cast from `oop` to `oopDesc*` is handled by the `oopDesc* ()` operator. I think we should keep `oop obj = _wh.peek();` for consistency with the return type declared in `peek`. 

For the issue with `obj != _obj`, changing `obj != cast_to_oop(_obj)` resolves it.

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

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