OpenJDK8 Thread.sleep will deadlock while turn down system date time.

[Jung-uk Kim]

On 04/11/2017 19:55, Daniel Eischen wrote:
> On Tue, 11 Apr 2017, Eric van Gyzen wrote:
> 
>> On 4/8/17 2:03 AM, Konstantin Belousov wrote:
> [ ... ]
>>>
>>> If JVM sets timeouts using absolute times than it might be fixed in
>>> latest
>>> HEAD and stable/11.
>>
>> The JVM uses pthread_cond_timedwait() to implement Thread.sleep(), so
>> it always uses absolute times.  Furthermore, it uses the default
>> clock, CLOCK_REALTIME.  My recent change (r315280) does not fix this
>> behavior; in fact, I believe it will make the problem worse, since
>> moving the clock forward will wake the thread prematurely.
>>
>> I think the JVM should be fixed to use CLOCK_MONOTONIC.  Would someone
>> like to do the research to determine the correct behavior of
>> Thread.sleep()? Specifically, should the duration of the sleep be
>> affected by adjustments to the real-time clock?  I expect that it
>> should /not/ be affected, especially since the API takes a
>> relative/interval time.  Ideally, we would find the answer in the
>> formal language specification; failing that, I would be satisfied with
>> empirical data from testing on Windows, Linux, MacOS, and Solaris. 
>> I'll be happy to write a patch once we know what it should do.
>>
>> Please keep me CC'd, since I'm not on freebsd-java at .  (Thanks for the
>> CC, Kostik.)
> 
> It seems CLOCK_REALTIME behavior has bugged Linux in the past, too.  I
> think using CLOCK_MONOTONIC, perhaps via pthread_condattr_setclock() in
> our JVM, would be the better approach.

http://bugs.java.com/view_bug.do?bug_id=6900441
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/2e6938dd68f2

Basically, it was fixed in Linux source but it wasn't merged to ours
somehow.

Please try the attached patch.

> You'd probably also want to check that whatever java.util.concurrent
> relies on, if different, also behaves similarly (monotonically).

Runtime behaviour depends on HotSpot implementation.

Jung-uk Kim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openjdk8.diff
Type: text/x-patch
Size: 12706 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-java/attachments/20170412/dda3e17f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-java/attachments/20170412/dda3e17f/attachment.sig>