RFR: 8297168: Provide a bulk OopHandle release mechanism with the ServiceThread [v2]

[Coleen Phillimore]

On Mon, 21 Nov 2022 09:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When a `JavaThread` terminates it has to release all `OopHandles` that it uses. This can't be done by the thread itself due to timing issues, so it is handed-off to the `ServiceThread` to do it - ref [JDK-8244997](https://bugs.openjdk.org/browse/JDK-8244997).
>> 
>> Initially there was only one `OopHandle` to handle - that of the `threadObj`, but since Loom there are another 3 `OopHandles` to process. The existing logic does the hand-off one `OopHandle` at a time but that is a potential synchronization bottleneck because each hand-off acquires the `ServiceLock`, enqueues the `OopHandle`, issues a notify to (potentially) wakeup the `ServiceThread` and then releases the `ServiceLock`. This can lead to high contention on the `ServiceLock` and also bad scheduling interactions with the `ServiceThread`.
>> 
>> This PR contains two commits. The first simply changes the API so that we pass the target `JavaThread` so that all 4  `OopHandles` can be extracted in one call. The second commit looks at streamlining things further by consolidating  into a single `OopHandleList` instance.
>> 
>> As `ServiceThread is a subclass of `JavaThread` I wasn't concerned about it having detailed knowledge of the JavaThread implementation.
>> 
>> Testing:
>>   - tiers 1-3
>>   - checked still no memory leak (ref [JDK-8296463](https://bugs.openjdk.org/browse/JDK-8296463))
>> 
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rehn comments

I'm still not happy that ServiceThread knows all about JavaThread's fields that need to be cleared. But all of the OopHandleList code that's in serviceThread.cpp should be moved to javaThread.cpp. And two new functions added to JavaThread for ServiceThread to call (has_oop_handles_to_release and release_oop_handles).
I still think it's better since JavaThread is the only thing that has the necessity of deferred release.

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

Changes requested by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11254