JVM64bit running on Linux 64bit: when system time changes the JVM may hang (bug_id=6900441)

[bruno bossola]

Hi Andrew,

Thanks for your answer.  That's probably correct in the sense this is what
the code is doing :) I won't discuss that at all.

However pthread_cond_timedwait uses by default, as clock id, CLOCK_REALTIME
which, unfortunately is affected by settime()/settimeofday() calls (on
Linux): for that reason it cannot be used to measure nanoseconds delays,
which is what the specification requires. CLOCK_REALTIME is not guaranteed
to monotonically count as this is the actual "system time": each time my
system syncs time using a NTP server on the net, the time might jump
forward or backward. The correct call (again on Linux)  would require to
use CLOCK_MONOTONIC as clock id.

Your point would be that, based on Posix specs, setting the value of the
CLOCK_REALTIME clock using clock_settime() should have no effect on threads
that are waiting. Is that correct?

Cheers,

    Bruno






On Mon, Sep 2, 2013 at 3:42 PM, Andrew Haley <aph at redhat.com> wrote:

> On 09/02/2013 03:19 PM, bruno bossola wrote:
> > I cannot see this as a kernel bug, sorry, as the kernel is (now?)
> behaving
> > as expected.
>
> That's correct, and it's what I said.
>
> > it looks that, for various reason, the JVM is not using a
> > monotonic clock for nanos wait, and under certain conditions a lot of
> > primitive functions become not reliable.
>
> That's correct.  It's using pthread_cond_timedwait(), as I also said.
>
> Andrew.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130902/1115dbaf/attachment.html