RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset command
david.holmes at oracle.com
Tue Jan 26 22:29:29 UTC 2016
Thanks for the Review and vote Dan!
I'll wait to see if there are other opinions, but I'm leaning to adding
an experimental flag. Not sure about planning for its removal though -
that will be after 1000+ processor systems are common place :)
On 27/01/2016 7:47 AM, Daniel D. Daugherty wrote:
> On 1/26/16 2:12 PM, David Holmes wrote:
>> 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
>>> 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)
>> 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
> My vote:
> -XX:+UnlockExperimentalVMOptions -XX:+DynamicConfiguredCPUPath
> With a plan (and a bug) to remove that option down the road.
> And a code review.
> No comments.
> No comments.
> Nice test. I like that the default (no args) runs a set of tests
> and if you (manually) run the test with a specific arg it will
> check just that one value.
> Thumbs up! (Assuming you change UseNewCode to something else or
> delete its use all together.
>>> - 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