RFR 9: 8065372: Object.wait(ms, ns) timeout returns early

[Martin Buchholz]

Thanks, looks good to me!

On Wed, Nov 19, 2014 at 7:21 AM, roger riggs <roger.riggs at oracle.com> wrote:
> Hi,
>
> Created a new issue and webrev for this correction:
>
> Please review:
>
>    http://cr.openjdk.java.net/~rriggs/webrev-wait-8065372/
>
> Roger
>
>
> On 11/18/2014 11:02 AM, Martin Buchholz wrote:
>>
>> Here I'm just trying to fix the problem that Object.wait(millis,nanos)
>> trivially returns early.
>>>
>>> That seems overly complex - after checking for valid values of timeout
>>> and
>>> nanos you simply need:
>>>
>>> if (nanos > 0) timeout++;
>>>
>>> to ensure the >= requirement.
>>
>> Sure, the miminal diff is:
>>
>> diff --git a/src/java.base/share/classes/java/lang/Object.java
>> b/src/java.base/share/classes/java/lang/Object.java
>> --- a/src/java.base/share/classes/java/lang/Object.java
>> +++ b/src/java.base/share/classes/java/lang/Object.java
>> @@ -453,7 +453,7 @@
>>                                   "nanosecond timeout value out of
>> range");
>>           }
>>
>> -        if (nanos >= 500000 || (nanos != 0 && timeout == 0)) {
>> +        if (nanos != 0) {
>>               timeout++;
>>           }
>>
>>> But seriously we should just deprecate this version as we're not likely
>>> to
>>> get any underlying OS mechanisms for doing nanosecond resolution timed
>>> blocking actions.
>>
>> Object.wait(millis, nanos) is an ugly API (I wish for both a public
>> and hotspot internal API that simply operated on nanoseconds), but
>> it's not totally awful.  It's not obvious to me that computing
>> advances over the lifetime of the java platform won't allow
>> sub-millisecond scheduling, and other APIs that do operate on
>> nanoseconds (like Process.waitFor) should call this API.
>
>