RFR: 8209976: Improve iteration over non-JavaThreads
Kim Barrett
kim.barrett at oracle.com
Mon Aug 27 16:09:09 UTC 2018
> On Aug 27, 2018, at 5:22 AM, Roman Kennke <rkennke at redhat.com> wrote:
>
> Hi Kim,
>
> may I ask what is the motivation for this? How does it improve the
> situation?
I got here from JDK-8209850, and from JDK-8209974 by way of
JDK-8209975. (There are already links and some comments in JIRA to
indicate the connections.)
For JDK-8209974 I want to make use of the per-thread SATB and dirty
card queues for which space is already allocated in non-JavaThreads.
While working on that I discovered there can be non-JavaThreads
created before the the barrier set, so don't currently have
BarrierSet::on_thread_created applied to them, leaving the
GCThreadLocalData uninitialized. That's JDK-8209975.
To solve JDK-8209975 I want to iterate over all the non-JavaThreads
that exist when set_barrier_set is called, applying the (now deferred
rather than plain missing) on_thread_created calls. But the current
implementation of Threads::non_java_threads_do doesn't work yet at
that time (there are multiple places where it crashes), and not all
non-JavaThreads are NamedThreads (the other available iterator).
(For JDK-8209974 there is some additional work to be done for
non-JavaThreads around BarrierSet::on_thread_attach/detach.)
We already have iteration over all JavaThreads. Several use-cases for
iterating over the others (or some selected subsets) exist and are not
presently well supported. Hence this.
This also eliminates some possibly awkward special cases from
GlobalCounter. Hm, except that I seem to have forgotten to remove the
now obsolete asserts from GlobalCounter::critical_section_begin/end.
>
> Thanks,
> Roman
>
>> Please review this change to improve the iteration over
>> non-JavaThreads. […]
>>
>> 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