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

David Holmes david.holmes at oracle.com
Tue Jan 26 21:12:24 UTC 2016

Update ...

On 22/01/2016 6:06 PM, David Holmes wrote:
> 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)

I have been told that using the development flag UseNewCode in released 
code is a bad idea because it is used internally during development (as 
per its defined purpose).

I would like to be able to test the dynamic path easily, but I didn't 
want to pay the price of adding a new VM option to do it. So choices are:

a) don't do anything (remove the UseNewCode check)
b) add a new diagnostic flag
c) add a new experimental flag



>   - 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