(XS) RFR: 8148766: Test AvailableProcessors.java got wrong number of processors
David Holmes
david.holmes at oracle.com
Tue Feb 2 10:30:12 UTC 2016
On 2/02/2016 7:50 PM, Dmitry Samersoff wrote:
> David,
>
> Should we check that available > 0 ?
That is checked in the VM via an assert. But I can add that.
Thanks,
David
> Looks good for me.
>
> -Dmitry
>
> On 2016-02-02 05:15, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148766
>>
>> webrev: http://cr.openjdk.java.net/~dholmes/8148766/webrev/
>>
>> It seems some (arguably ill-behaved) systems can use aggressive power
>> management to disable cores on the fly and at high frequency. As a
>> result even using taskset the number of processors reported as available
>> to the JVM can be less than what we asked for. This small tweak to the
>> test simply changes the success criteria to only see more than the
>> expected number of processors as an error.
>>
>> Thanks,
>> David
>>
>> --- old/test/runtime/os/AvailableProcessors.java 2016-02-01
>> 21:14:07.721558368 -0500
>> +++ new/test/runtime/os/AvailableProcessors.java 2016-02-01
>> 21:14:05.681443769 -0500
>> @@ -27,7 +27,7 @@
>>
>> /*
>> * @test
>> - * @bug 6515172
>> + * @bug 6515172 8148766
>> * @summary Check that availableProcessors reports the correct value
>> when running in a cpuset on linux
>> * @requires os.family == "linux"
>> * @library /testlibrary
>> @@ -93,7 +93,9 @@
>>
>> static void checkProcessors(int expected) {
>> int available = Runtime.getRuntime().availableProcessors();
>> - if (available != expected)
>> + // available can dynamically drop below expected due to
>> aggressive power management
>> + // but we should never have more than expected, else taskset is
>> broken
>> + if (available > expected)
>> throw new Error("Expected " + expected + " processors, but
>> found "
>> + available);
>> else
>
>
More information about the hotspot-runtime-dev
mailing list