ThreadPriorityPolicy settings for non-root users

Fri Dec 21 12:47:11 UTC 2018

On 21/12/2018 9:24 pm, Lindenmaier, Goetz wrote:
> Hi David,
> 
> Yes, as Matthias stated we have at least one application that relies on
> thread priorities. Their going to Java 11 is blocked by this.

I'd like to hear more. I'd be very surprised that any actual functional 
correctness issue is addressed by playing with niceness.

> Also are you aware that this is the implementation of Thread.setPriority()?

There are no specified semantics for Thread priorities in Java, as they 
pertain to operating system priorities, or relative scheduling across 
processes. So there is nothing broken with regard to the specification 
with the default behaviour (ThreadPriorityPolicy=0).

> So isn't it great we finally fix the old and bit-rotten code that implements
> this official method?

No. Thread priorities are a minefield. Giving threads priorities was one 
of the biggest mistakes in the Java thread API. People were advised to 
just forget about them 20+ years ago - and most took that advice. I 
think the only reason this wasn't all stripped out years ago was some 
corner cases with Solaris scheduling classes.

If you want to just disable the root check to get back the erroneous 
ThreadPriorityPolicy=2 behaviour then file a bug and a CSR and propose a 
patch. I don't think we want yet another flag for this though. Just drop 
the root check for ThreadPriorityPolicy=1 and let the underlying system 
permissions control success or failure.

David

> Best regards,
>    Goetz.
> 
> 
>> -----Original Message-----
>> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of
>> David Holmes
>> Sent: Freitag, 21. Dezember 2018 11:56
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: ThreadPriorityPolicy settings for non-root users
>>
>> On 21/12/2018 6:39 pm, Baesken, Matthias wrote:
>>> Hi  David  ,   it might be  that  the functionality  is  seen as not very helpful
>> by some and removed  or deprecated  in  some future  Java release.
>>>
>>> However it is present in the current JDKs and should work there nicely .
>>
>> Sorry but that's a bit naive. The code is old and bit-rotted and in some
>> cases (Mac port) likely never used, so the idea that "it's there so it
>> should work" is just not realistic - sorry.
>>
>>> Currently  I have some points I do not like about the current state :
>>>
>>> - the root-check  is not consistent , it is present  on Linux /  BSD (Mac)     but
>> I don't see it on Solaris
>>
>> Wasn't needed on Solaris. User-level capabilities sufficed.
>>
>>> - It  ignores currently  the  CAP_SYS_NICE capability
>>
>> It never supported it. AFAIK the linux code doesn't really support any
>> capability based permissions.
>>
>>> - it ignores that  setting a  higher niceness works nicely  on most OS
>> (checked Linux/Solaris/BSD)  without being root  (or having special
>> capabilities)
>>
>> The priority control was never really about tweaking niceness levels.
>>
>>> -  the root check makes testing hard  (maybe that's why the Mac version
>> was a bit broken?)
>>
>> Running under sudo isn't that hard.
>>
>> Sorry I'm not very supportive here - this isn't something that needs
>> some minor tweaking to bring back online, it's something that may never
>> have worked well in the first place.
>>
>> Have you got real use cases for this?
>>
>> Cheers,
>> David
>>
>>>
>>> Best regards, Matthias
>>>
>>>
>>>> -----Original Message-----
>>>> From: David Holmes <david.holmes at oracle.com>
>>>> Sent: Donnerstag, 20. Dezember 2018 12:06
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>>> Subject: Re: ThreadPriorityPolicy settings for non-root users
>>>>
>>>> Hi Matthias,
>>>>
>>>> The more I think about this the more I see it as a huge can of worms.
>>>> There are very, very, limited usecases for managing the priority of
>>>> individual threads within a running Java application. Adjusting the
>>>> process priority/nice-ness is effective and much simpler.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>> On 20/12/2018 3:13 am, Baesken, Matthias wrote:
>>>>>
>>>>> Hello ,
>>>>>      currently OpenJDK supports 2 ThreadPriorityPolicy settings,  0
>> (normal,
>>>> the default) and 1,
>>>>> the so called "aggressive" mode :
>>>>>
>>>>> "1 : Aggressive.                                                 "\
>>>>> "    Java thread priorities map over to the entire range of      "\
>>>>> "    native thread priorities. Higher Java thread priorities map "\
>>>>> "    to higher native thread priorities. This policy should be   "\
>>>>> "    used with care, as sometimes it can cause performance       "\
>>>>> "    degradation in the application and/or the entire system. On "\
>>>>> "    Linux this policy requires root privilege.")                 \
>>>>>
>>>>> Currently  we check directly for root in os_bsd.cpp and os_linux.cpp (the
>>>> text  in globals.hpp mentions only Linux which seems to be not fully
>> correct):
>>>>>
>>>>> if (geteuid() != 0) { ... } in function prio_init().
>>>>>
>>>>> (looks like the check is not done for other platforms).
>>>>>
>>>>> However the check for root (e.g. on Linux)  hinders users to set a
>>>> ****lower priority**** for a thread (== increase the "niceness" level)
>>>>> when running as a non-root user  (there might be strange ways from
>>>> outside the VM with calling scripts and renice but .... ).
>>>>>
>>>>>
>>>>> In older JDKs (e.g. JDK8) there was a "workaround" to use for example
>>>> ThreadPriorityPolicy=2 to avoid the root-check,
>>>>> but this is not possible any more in recent JDKs (10/11) after the range
>>>> check (0,1) has been introduced for the ThreadPriorityPolicy flag
>>>>> (and probably the old workaround was not a good one anyway because
>> it
>>>> was undocumented).
>>>>>
>>>>> So do you think we could introduce another XX-flag  (
>>>> AllowAggressiveThreadPriorityPolicyForAllUsers, or some better name)
>>>>> that allows using the "aggressive" mode for non-root users ? Another
>>>> option would be to add another mode 2 for ThreadPriorityPolicy
>>>>> that documents the behavior (like mode 1 but without root-user check).
>>>>>
>>>>> If I get it right, even  setting  ***higher prios*** (lower niceness) is
>>>> possible for non-root users on systems configured in an appropriate way
>>>>> (using the CAP_SYS_NICE capability).
>>>>>
>>>>> But setting  lower prio / higher niceness is even possible for normal users
>>>> NOW without special config, it is just disabled by the root-check
>>>>> which is very bad.
>>>>>
>>>>> Best regards, Matthias
>>>>>