addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcredit-cardcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobe--smallglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1launch-new-window--smalllight-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [ljc] JVM is messed up when system clock is rolled backward

From: Bruno B.
Sent on: Tuesday, September 3, 2013 2:19 PM
Well, the thing that worries me is that, anyway, the bug is still a P4 planned for JDK9: in my experience P4 means "we will never fix it" :)

I did not manage to write a patch myself (you basically have to change the cpp code of the hotspot VM) but I could do that, if I have time. At the moment I just reimplemente the sleep() which, to me, is useless: the whole park()/unpark() functions family have to be rewritten.

Cheers,

    Bruno



On Tue, Sep 3, 2013 at 1:54 PM, Martijn Verburg <[address removed]> wrote:
Looks like the discussion is going well over at hotspot-runtime - although it sounds like the short-term solution is to use your own patched JVM (as you've done).

Cheers,
Martijn


On 3 September[masked]:06, Bruno Bossola <[address removed]> wrote:
Thanks for your answer, I did not report back here the discussion with the engineers of the hotspot VM, I will try to summarize where we are atm.

True, the daylight saving will be sorted by TZ adjustments (thank god!) BUT the implementation of the concurrency primitive LockSupport.parkNanos(), the function that controls *every* concurrency primitive on the JVM, is flawed, and any NTP sync, or system time change, will break it (with different and funny results, yuppie!)

To be more clear about the issue, the extent of it and the concurrency library, let me introduce this very simple program:

import java.util.concurrent.locks.LockSupport;

public class Main {

    public static void main(String[] args) {

        for (int i=100; i>0; i--) {
            System.out.println(i);
            LockSupport.parkNanos(1000L*1000L*1000L);
        }

        System.out.println("Done!");
    }
}


Run it with a 64bit 1.6+ JVM on 64bit Linux, turn the clock down one hour and wait until the counter stops... magic!  I tested this on JDK6, JDK7 and latest JDK8 beta running on various Ubuntu distros. It's not just a matter of (old?) sleep() and wait() primitives, this issue it affects the whole concurrency library.

To prove that this is fixable, I reimplemented the program above above substituting  LockSupport.parkNanos()  with  a JNI call to clock_nanosleep(CLOCK_MONOTONIC...): works like a charm :(

This is due to the fact  that the CPP code is calling the pthread_cond_timedwait() using its default clock (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, which are defined by POSIX specs since 2002. (or better CLOCK_MONOTONIC_RAW)

The POSIX spec is infact clear, as it states "...setting the value of the CLOCK_REALTIME clock via clock_settime() shall have no effect on threads that are blocked waiting for a relative time service based upon this clock...": it definitely states "relative".  Having a look at the hotspot code, it appears that the park() is using compute_abstime() (which uses timeofday) and then waits on an absolute period: for that reason it's influenced by the system clock change.
Very wrong
.

Consequences? If a system time change happens then all the threads parked will hang, with unpredictable/corrupted/useless results to the end user. Same applies to Future, Queue, Executor, and any other construct that it's somehow related to concurrency. This is a big issue for us and for any near time application: please think about trading and betting, where the JVM is largely used. And please do not restrain yourself to the Java language: add Scala and any other JVM-based language to the picture.

Hope this clears the confusion :), and I am still VERY scared.
Cheers,

   Bruno

p.s.
BTW I somehow managed to have the bug reopened to the public... a small step for a man, a giant leap for the JVM :)









--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Bruno Bossola ([address removed]) from LJC - London Java Community.
To learn more about Bruno Bossola, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Martijn Verburg ([address removed]) from LJC - London Java Community.
To learn more about Martijn Verburg, visit his/her member profile

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy