JDK-8151594 : Move concurrent refinement thread activation logging out of GC pause
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2016-03-10
  • Updated: 2021-12-07
  • Resolved: 2021-11-30
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.
JDK 18
18 b26Fixed
Related Reports
Relates :  
JDK-8133051 - Concurrent refinement threads may be activated and deactivated at random
Description
The logging changes that were part of JDK-8150134 made it apparent that refinement thread 0 (the "primary" refinement thread) sometimes gets activated during a pause, though fortunately seems to immediately get blocked on the SuspendibleThreadSetJoiner.
Comments
Changeset: 65251f76 Author: Kim Barrett <kbarrett@openjdk.org> Date: 2021-11-30 22:43:53 +0000 URL: https://git.openjdk.java.net/jdk/commit/65251f76937d1844e2235ce64b42b17f4492d20e
30-11-2021
It's intentional that the primary (worker 0) refinement thread may be activated during a pause. G1ConcurrentRefine::adjust activates it if it is inactive and should be active according to the newly adjusted activation threshold. The problem is that it may log the activation during the pause, which is somewhat confusing. This happens because the G1CRT activation logging is before the STS entry. It would be better if the activation logging were after the STS entry, so it isn't intermixed with pause-related logging.
25-11-2021