JDK-8217343 : Shenandoah control thread should be able to run at critical priority
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8-shenandoah,11-shenandoah,12,13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-01-17
  • Updated: 2019-09-06
  • Resolved: 2019-01-19
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 12 JDK 13
12.0.2Fixed 13 b05Fixed
Related Reports
Blocks :  
JDK-8217378 - UseCriticalCMSThreadPriority is broken
Description
Current Shenandoah control thread runs with the default priority (NearMaxPriority):

ShenandoahControlThread::ShenandoahControlThread():
  create_and_start();

ConcurrentGCThread:
  // Create and start the thread (setting it's priority.)
  void create_and_start(ThreadPriority prio = NearMaxPriority);

CMS and others are able to use critical thread priority, for example:

  create_and_start(UseCriticalCMSThreadPriority ? CriticalPriority : NearMaxPriority);

We should consider doing the same for Shenandoah.
Comments
Fix Request Backporting this patch keeps Shenandoah codebases in sync across JDK releases. Patch applies cleanly and passes hotspot_gc_shenandoah, including new test. The fix is contained in Shenandoah code, and therefore risk is minimal.
14-02-2019
Ah, oops, critical priorities are broken themselves, see JDK-8217378.
18-01-2019