RFR: 8357539: TimeSource.now() is not monotonic
Jaikiran Pai
jpai at openjdk.org
Thu May 22 10:38:53 UTC 2025
On Thu, 22 May 2025 09:59:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:
>> We observed a case where the instants returned by `TimeSource.now()` were returned in non-monotonic order. The reason was that sometimes we were using a delay calculated with one `localSource` as an input to a different (updated on another thread) `localSource`. This was confirmed by putting `assert firstNanos + delay == nanos;` under `instant(long, long)`.
>>
>> The fix ensures that we won't accidentally use the incorrect delay by removing the `instant(long, long)` overload, and calculating the delay in the method where it is used.
>>
>> No new test; instrumenting this class for testing would likely double its size.
>
> src/java.net.http/share/classes/jdk/internal/net/http/common/TimeSource.java line 97:
>
>> 95: // use localSource if possible to avoid a volatile read
>> 96: if (source.isInWindow(delay)) {
>> 97: return source.instant(nanos);
>
> I would keep the two args intant() method which avoids computing the delay twice. Using a local variable `source` in this method should be enough to solve the bug.
Hello Daniel, with this proposed change, is there any reason to have the `localSource` field in this `TimeSource` anymore?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25390#discussion_r2102234265
More information about the net-dev
mailing list