Use of raw oops, like JavaThread::_threadObj, introduce tight coupling between the runtime and GC code, and can constrain how the GC must operate to ensure such oops are maintained correctly (i.e. by calling oops_do when needed).

The OopStorage API was introduced to allow decoupling of the runtime and the GC in this area, so we should look at converting the _threadObj to use OopStorage.

There are a couple of complexities to consider here:

1. The _threadObj oop is also accessed directly by the JIT code as an intrinsic implementation for java.lang.Thread:;currentThread(). That method has always been "hot" with regard to performance so we need to ensure performance is maintained.

2. The time that we would want to clear the _threadObj storage is after the JavaThread is no longer on any secondary ThreadsLists (just before, or as part of JavaThread destructor execution). However at that time it is not allowed for the terminating thread to interact with OopStorage. Consequently we would have to hand off to another thread (e.g. the ServiceThread) to do the release. A synchronous handoff is relatively simple but might introduce a serialization bottleneck for thread termination. An asynchronous handoff requires a queue and appropriate locking strategies that then have to interact with the Service_lock correctly. This could also have performance implications.

Note that since JDK-8240588 we handle the "clearing' of _threadObj via the exiting threads list, which is walked by Universe::oops_do at a safepoint.