JDK-8202839 : ThreadService get_live_thread_count/get_daemon_thread_count
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2018-05-09
  • Updated: 2018-10-09
  • Resolved: 2018-10-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbd_majorResolved
Related Reports
Duplicate :  
JDK-8021335 - Missing synchronization when reading counters for live threads and peak thread count
Relates :  
JDK-8202564 - java/lang/management/ThreadMXBean/ThreadCounts.java fails
Description
_exiting_threads_count, _exiting_daemon_threads_count, _daemon_threads_count, _live_threads_count
These four variables are changed together under Threads_lock, but we read them without Threads_lock.

get_live_thread_count/get_daemon_thread_count sometimes return a negative value, e.g  if you first load _daemon_threads_count => several threads then starting to exiting, when you load _exiting_daemon_threads_count it can be larger, and we return a negative number.

TEST FAILED: Minimal number of daemon thread count is 21ThreadMXBean.getDaemonThreadCount() returned 15
TEST FAILED: Minimal number of daemon thread count is 21ThreadMXBean.getDaemonThreadCount() returned 15
TEST FAILED: Minimal number of daemon thread count is 0ThreadMXBean.getDaemonThreadCount() returned -6
TEST FAILED: Minimal number of daemon thread count is 0ThreadMXBean.getDaemonThreadCount() returned -6
TEST FAILED: Minimal number of daemon thread count is 0ThreadMXBean.getDaemonThreadCount() returned -6
TEST FAILED: Minimal number of daemon thread count is 0ThreadMXBean.getDaemonThreadCount() returned -6
Comments
Same issue as JDK-8021335
09-10-2018
I believe 8202564 will make this problem very unlikely to happen. But still an issue. Ignore that we call the remove before we stay around for SMR threadslist. So Threads_lock is the easy way out.
09-05-2018
Moving from hotspot/runtime -> hotspot/svc since this is about the HotSpot code that implements a java.lang.management API...
09-05-2018
The error messages shown in the description are the same as the ones reported in: JDK-8202564 java/lang/management/ThreadMXBean/ThreadCounts.java fails Martin fixed the failure mode in JDK-8202564 by rearranging the code that managed one of the counters. However, Robbin's observations about the fields being managed by this M&M code being racy remain valid. I don't know if Robbin wants to keep this bug open or close it as a duplicate of JDK-8202564.
09-05-2018