JDK-7091418 : FX priority class from Solaris should be available to JVM
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7u2
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris
  • CPU: generic
  • Submitted: 2011-09-16
  • Updated: 2019-01-18
  • Resolved: 2012-01-24
Related Reports
Duplicate :  
Relates :  
Description
The FX class priorities should be available from within the JVM.  Diffs attached
Solaris has an FX priority class that when certain threads are boosted to the highest priority (60) can gain significant performance advantages, especially on recent SPARC hardware.  This patch allows the JVM to map from FX class to the internal JVM priorities.  More work needs to be done to allow boosting individual threads to the highest priority.

Comments
SUGGESTED FIX Define a new Java pseudo-priority called CriticalPriority, just above MaxPriority. Compiler threads, the CMS background thread, and Java threads can have the os equivalent of this priority. On Solaris, this is the FX/60 scheduling class/priority. On other platforms, it's the same as MaxPriority's os priority. Add 3 new command line switches, all gated by UseExperimentalVMOptions. -XX:+UseCriticalJavaThreadPriority Maps Java MAX_PRIORITY to critical priority. -XX:+UseCriticalCompilerThreadPriority All compiler threads run at critical priority. -XX:+UseCriticalCMSThreadPriority The CMS background thread runs at critical priority. On Solaris, one must in addition use -XX:+UseThreadPriorities to use native priorities at all. Otherwise, Hotspot just accepts whatever Solaris decides. The Solaris implementation can only change priorities within the process scheduling class. It doesn't change scheduling classes on a per-thread basis. Add that capability (to set_lwp_priority) and use it for the critical thread work.
20-01-2012

EVALUATION Ok.
20-01-2012