RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset command

David Holmes david.holmes at oracle.com
Tue Jan 26 22:26:23 UTC 2016

Hi Jerry,

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.


> Jerry
>> 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
>> configured
>> 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
>> references.
>> Testing:
>>  - 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.
>> Thanks,
>> David

More information about the hotspot-runtime-dev mailing list