RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset command
david.holmes at oracle.com
Tue Jan 26 22:26:23 UTC 2016
On 27/01/2016 7:09 AM, Gerald Thornbrugh wrote:
> Hi David,
> Your code looks good. I do have a question about the test. If I
> understand the test correctly
> the test will be run with no parameters and will use the "taskset"
> command to determine the
> number of processors.
> Under what circumstances will the test be run with arguments?
The taskset command runs the test with arguments (the argument being the
expected number of processors). Notice that I prepend the taskset part
of the command to the original Java command, then append the expected
number of processors.
> Was this something you added to allow the verification of the
> "availbleProcessors" method to be done manually?
Yes this allows checking availableProcessors with different numbers of
processors being available.
>> First a special thanks to Martin Buchholz for his input, feedback,
>> critique and raising awareness of how non-simple this issue is.
>> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
>> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>> Basic problem:
>> processors available for use <= processors online <= processors
>> but we always returned the number of online processors.
>> Solution is simple in its basic form: use sched_getaffinity to get the
>> scheduling affinity mask and count the number of available processors.
>> Details are complicated by the desire to handle very large processor
>> systems. See the bug report for lots of detailed discussions and
>> - new test that verifies behaviour when running under taskset
>> - diagnostic hook injection (UseNewCodeN) to enable testing of all
>> code paths (one hook is left in for non-product to allow easy testing
>> of the dynamic path)
>> - JPRT
>> Compatability issues:
>> - the system code we're using now is at least 5 years old so distro's
>> older than that (which are not officially supported) may not work
>> - anyone already running under a processor constrained environment
>> (like Docker) and using availableProcessor() to "size" things, will
>> find that size has now changed. We do not expect this to be a problem
>> - on the contrary we expect Docker users to want the new behaviour.
More information about the hotspot-runtime-dev