RFR: 8209976: Improve iteration over non-JavaThreads

Kim Barrett kim.barrett at oracle.com
Mon Sep 3 22:06:26 UTC 2018

> On Sep 3, 2018, at 2:44 AM, David Holmes <david.holmes at oracle.com> wrote:
> Hi Kim,
> I know this has been pushed now but if we're going to re-jiggle the Thread hierarchy then we can maybe do better.

Thanks for looking anyway.

> I never liked the introduction of NamedThread and it seems even more superfluous now - all threads can/should have names, there's really no reason why the WatcherThread or JfrSamplerThread should be special in this regard.

NamedThread is described as being for cases where there can be
multiple threads of the same class. WatcherThread and JfrSamplerThread
can hard-code the name string in the name() implementation. Of course,
the same could be said for the VMThread, which *is* a NamedThread. I
think the VMThread is a NamedThread because there is some other stuff
associated with NamedThread, e.g. the GC id and _processed_thread.
There are clearly some oddities in this hierarchy; maybe someone should
think about cleaning this up a bit.

> Arguably you don't need NonJavaThread as if you don't derive from JavaThread then you are by definition a non-JavaThread - but if this classification makes things easier so be it.

NonJavaThread provides a place to hang the iteration over the threads
that aren't JavaThreads.  So yes, I think it makes this classification
easier. If the non-JavaThread list management were in create/destroy
wrappers rather than in the constructor and destructor I might feel

> IIRC we only use is_Java_thread() due to a lack of RTTI in our C++ usage. Is that likely to change going forward?

I don't have any expectation of a change in this area.  No, I don't
think using a newer language standard and *some* newer (or even
existing) features will require such a change.

> Meanwhile should is_Java_thread() be pure virtual in Thread and overridden in JavaThread and NonJavaThread ?

I tried to make is_JavaThread pure virtual to address Coleen's request
to make Thread abstract. That failed because of JDK-8210024.

> Cheers,
> David
> On 27/08/2018 9:09 AM, Kim Barrett wrote:
>> Please review this change to improve the iteration over
>> non-JavaThreads.  This change introduces a new base class
>> NonJavaThread, which should be a base for any Thread class that isn't
>> a JavaThread.  The recently introduced iteration over NamedThreads
>> (JDK-8209850) is moved to this new class.  This allows the
>> re-implementation of Threads::non_java_threads_do using that list.
>> Note: Perhaps CollectedHeap::gc_threads_do could be replaced by a
>> Threads::gc_threads_do that is implemented as an iteration over the
>> non-JavaThreads with a filter to select GC-related thread types.  That
>> isn't being done as part of this change though.
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8209850
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8209976/open.00/
>> Testing:
>> mach5 tier1-3, hs-tier4-5 in conjunction with a fix for JDK-8209975.
>> Local testing of just this change.

More information about the hotspot-dev mailing list