JDK-8149901 : [Solaris] Use of -XX:+UseThreadPriorities crashes fastdebug
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • Submitted: 2016-02-16
  • Updated: 2016-11-01
  • Resolved: 2016-05-20
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 9
9 b122Fixed
Related Reports
Relates :  
JDK-8038473 - Remove support for old T1 libthread
Relates :  
JDK-8169031 - [Solaris] JVM is blissfully unaware of the Fair Share Scheduler
Relates :  
JDK-8157010 - [Solaris] Clean out incorrect usage of library-level thread priority functions
Description
The native thread priority code on Solaris is disabled by default (UseThreadPriorities==false). The code seems to have bit-rotted as enabling it triggers an assertion failure:

 > ./build/solaris-x64-debug/images/jdk/bin/java  -XX:+UseThreadPriorities -version
# To suppress the following error report, specify this argument# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=
/os_solaris.cpp# after -XX: or in .hotspotrc:  SuppressErrorAt=/os_solaris.cpp:3486
:3486# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=
/os_solaris.cpp[thread 4 also had an error]
:3486
[thread 6 also had an error]
[thread 5 also had an error]
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/scratch/dh198349/jdk9-hs-rt/hotspot/src/os/solaris/vm/os_solaris.cpp:3486), pid=25072, tid=3
#  assert(newpri >= 0 && newpri <= 127) failed: bad priority mapping
#
# JRE version:  (9.0) (fastdebug build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-02-03-193213.daholme.jdk9-hs-rt, mixed mode, tiered, compressed oops, g1 gc, solaris-amd64)
# Core dump will be written. Default location: /scratch/dh198349/jdk9-hs-rt/core or core.25072
#
[thread 13 also had an error]
# An error report file with more information is saved as:
# /scratch/dh198349/jdk9-hs-rt/hs_err_pid25072.log
[thread 14 also had an error]
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 3
Dumping core ...


Fail with ThreadPriorityPolicy 0 and 1.
Comments
Given we know we are dealing with bound threads and there is no lwp to control as yet, we can simply push a default initial priority into the osThread instance, to be read back when the thread itself starts executing. Most thread types will override this default before actually starting the threads.
16-05-2016
Need to restore: // Set the default thread priority. If using bound threads, setting // lwp priority will be delayed until thread start. set_native_priority(thread, DefaultThreadPriority == -1 ? java_to_os_priority[NormPriority] : DefaultThreadPriority); but with no use of the now deprecated DefaultThreadPriority. Actually the code seems incorrect - as does the original thr_setprio version - as it should be setting the priority from the actual priority of the java.lang.Thread object. Update: the code was not incorrect - there is no binding between the JavaThread and the java.lang.Thread at this time so you can't read the Java priority. That is handled in JavaThread::prepare() which is called from JVM_StartThread.
16-05-2016
Probing deeper into this much of the Solaris priority code is "broken" and has likely been that way for a very long time - so I have filed JDK-8157010 to clean that up in JDK 10.
16-05-2016
The logic to set the priority was removed as part of JDK-8038473 which was supposed to be just removing the old T1 libthread support.
10-05-2016
We are failing because here: // If the creator called set priority before we started, // we need to call set_native_priority now that we have an lwp. // We used to get the priority from thr_getprio (we called // thr_setprio way back in create_thread) and pass it to // set_native_priority, but Solaris scales the priority // in java_to_os_priority, so when we read it back here, // we pass trash to set_native_priority instead of what's // in java_to_os_priority. So we save the native priority // in the osThread and recall it here. if (osthr->thread_id() != -1) { if (UseThreadPriorities) { int prio = osthr->native_priority(); We read back an uninitialized field. It seems that the code to save the native priority (as per the comment) has been removed at some point!
10-05-2016
The thread priority history is long and complex and very platform specific. While BSD and Linux set UseThreadPriorities to true, it is used in conjunction with a check of ThreadPriorityPolicy==0 - which it is - and the end result is effectively a no-op for thread priority and the result is the same as-if UseThreadPriorities were false. Windows is the only platform that uses native thread priorities by default. The Solaris support for native thread priorities is very complicated and allowed for use of different scheduling classes (IA, FX, or with extreme care RT).
20-04-2016
Research why there is a flag to turn off UseThreadPriorities and why Solaris is the only platform to have it set to false. Can we remove this flag?
23-02-2016