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

[roger riggs]

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.