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

[David Holmes]

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.

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

Commit messages:
 - Version 2: combine all 4 OopHandles into one OopHandleList instance
 - Version 1: simply enqueue all the OOpHandles in one call to the ServiceThread API

Changes: https://git.openjdk.org/jdk/pull/11254/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11254&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297168
  Stats: 34 lines in 4 files changed: 20 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11254.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11254/head:pull/11254

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