RFR: 8185529: JCK api/java_lang/Object/WaitTests failed with jdk10/hs nightly
David Holmes
david.holmes at oracle.com
Mon Oct 9 01:35:33 UTC 2017
Can I get a second review please.
Thanks,
David
On 7/10/2017 9:28 AM, David Holmes wrote:
> Thanks Dan!
>
> David
>
> On 6/10/2017 11:58 PM, Daniel D. Daugherty wrote:
>> Thumbs up!
>>
>> Dan
>>
>>
>> On 10/5/17 10:47 PM, David Holmes wrote:
>>> Bug is not public - sorry.
>>>
>>> webrev: http://cr.openjdk.java.net/~dholmes/8185529/webrev/
>>>
>>> Also patch inline below.
>>>
>>> Problem: o.wait(Long.MAX_VALUE) returns immediately
>>>
>>> Cause: arithmetic overflow gives a time in the past so the timeout
>>> expires immediately
>>>
>>> This was introduced by the fix for:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8174231 "Factor out and
>>> share PlatformEvent and Parker code for POSIX systems."
>>>
>>> while we go to great lengths to ensure we avoid overflows inside the
>>> time calculation functions, I overlooked the fact that we now first
>>> convert a millisecond value into nanoseconds, which can overflow.
>>>
>>> Fix: limit the millis value to the existing hard limit of
>>> MAX_SECS*MILLIUNITS ms. That can not overflow when converted to nanos.
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>> --- old/src/hotspot/os/posix/os_posix.cpp 2017-10-06
>>> 00:34:31.595159338 -0400
>>> +++ new/src/hotspot/os/posix/os_posix.cpp 2017-10-06
>>> 00:34:29.443037883 -0400
>>> @@ -1770,6 +1770,12 @@
>>>
>>> if (v == 0) { // Do this the hard way by blocking ...
>>> struct timespec abst;
>>> + // We have to watch for overflow when converting millis to nanos,
>>> + // but if millis is that large then we will end up limiting to
>>> + // MAX_SECS anyway, so just do that here.
>>> + if (millis / MILLIUNITS > MAX_SECS) {
>>> + millis = jlong(MAX_SECS) * MILLIUNITS;
>>> + }
>>> to_abstime(&abst, millis * (NANOUNITS / MILLIUNITS), false);
>>
More information about the hotspot-runtime-dev
mailing list