Bug ID: JDK-4813310 Map Thread priorities to system thread/process priorities

Type: Enhancement
Component: hotspot
Sub-Component: runtime
Affected Version: 1.4.1,5.0

Priority: P3
Status: Closed
Resolution: Fixed
OS: linux
CPU: x86

Submitted: 2003-02-05
Updated: 2012-10-13
Resolved: 2005-10-13

JDK 6
6 b56Fixed

I inspected several JVMs for their background threading support:
                       
Linux Sun JVM 1.4.1             no
Linux Sun JVM 1.3.1             no
Linux Blackdown JVM 1.4.1 beta  no
Linux Bea JVM 1.4               --  
Linux IBM JVM 1.4               no
Solaris Sun JVM 1.4.1           no
MacOS-X Apple JVM 1.4.1-a7      yes
Windows Sun JVM 1.4.1           yes

no - behaves like simple round-robin scheduler (ignoring priorities).

A sample microbenchmark attached.
###@###.### 10/14/04 14:28 GMT

EVALUATION ------------------ Updated: January 30, 2007 To clarify the "fix" here, all that is done is to adjust the "niceness" of the kernel thread that is presumed to be bound to the Java thread by calling setpriority(). This does not provide strict priority preemptive scheduling as it is still done within the SCHED_OTHER scheduling policy by default. This means that lower "priority" threads will gradually increase in priority (priority ageing) as each timeslice elapses. Hence all threads will get a chance to run. The Hotspot VM will not work reliably under strict priority preemptive scheduling - for that you need a real-time Java implementation such as Sun's Java Real-Time System (Java RTS): http://java.sun.com/javase/technologies/realtime.jsp Also note that Thread.yield itself is not specified to be priority-based - there is no requirement that a high priority thread returns immediately from yield if only lower priority threads are runnable. In contrast OS "yield" operations are often defined in terms of priority (eg. placing the current thread at the tail of the queue for its priority level), such as the linux sched_yield method which is actually used for Thread.yield on linux. However sched_yield's behaviour is defined in terms of the static priority of the thread (really process) and that value is always zero under SCHED_OTHER, so regardless of the nice level, sched_yield will relinquish the processor if another thread is ready.
30-01-2007
EVALUATION ---------------------------------- Fixed by using setpriority() in root mode. To use thread priority on Linux, the application needs to run as root and -XX:ThreadPriorityPolicy=1 is set on the command line, otherwise thread priorities are ignored.
05-10-2005
EVALUATION In the last two weeks, I've been testing Java threads with SCHED_RR policy. Unlike SHCED_OTHER, SCHED_RR allows static priority (1-99) and it puts the thread in real-time scheduling class. SCHED_RR requires root privilege. The idea is, if SCHED_RR works OK, at least we could support Java priority if the application is run by privileged user. However, the bad news is that SCHED_RR does not work. For small apps, it seems fine, but for heavily multi-threaded application (e.g. volano), it hangs easily. This happened on various Linux distributions and multiple machines, with both old and the O(1) scheduler. It's not a hang in the application, but the entire system locked up and required a power cycle. The data that I collected from the few successful runs aren't promising either. Comparing to SCHED_OTHER, the same benchmark is slower with SCHED_RR, sometimes by a large margin. See comments for data. My conclusion from the tests is that SCHED_RR policy is not for multi-threaded application like java. The only remaining "choice" is setpriority() for privileged users. But I'm not yet convinced it's worthwhile.
28-09-2005
WORK AROUND Yielding see 4799163 ###@###.### 2003-03-24
24-03-2003
EVALUATION It is intentional that the JLS provides little in the way of guarantees regarding the behavior of thread priorities. It is not feasible to provide guarantees that apply across platforms with markedly different underlying threading models. As a consequence, developers are well advised to limit their use of thread priorities to fine-tuning the responsiveness of a working application. This is discussed in detail in Joshua Bloch's "Effective Java Programming Language Guide", Item 51 ("Don't depend on the thread scheduler"). That said, it is possible that the Java platform threading implementation on Linux doesn't take full advantage of the underlying threading implementation. I leave it to the VM group to make this determination. ###@###.### 2003-02-11 ---------------------------------------------- It's well documented that the default Linux scheduling policy SCHED_OTHER (btw, this is the only scheduling policy that can be used by non-priviledged users) uses static priority 0 for all threads/processes. Every thread has the same priority. However, kernel scheduler does try to give interactive tasks a higher priority than CPU hogs, but that's not something can be controlled by user apps. The only way around this is to exploit the fact that threads are indeed processes and use process niceness to simulate thread priorities. But doing so inside JVM is inappropriate because it's based on a broken model (Linux pthread itself is moving away from the non-POSIX thread-is-process model) and it doesn't really solve the problem (non-root user can only lower priority but not the opposite). This RFE will not be fixed until Linux scheduler can support true thread priorities. ###@###.### 2003-02-18
18-02-2003

Duplicate :	JDK-5096173 - Thread.setPriority() doesn't work: The system call fails (EINVAL) on Linux.
Relates :	JDK-6512687 - Bug #4813310 (Linux thread priority support) marked as Closed, fixed but is not.
Relates :	JDK-4985566 - Equal priority threads not timslicing properly in Linux
Relates :	JDK-6495300 - JRE Thread Priority Mapping In Red Hat Linux
Relates :	JDK-6541879 - Thread.sleep() within a synchronized block influences subsequent lock aquisition