From owner-freebsd-java@freebsd.org Sun Apr 9 05:31:01 2017 Return-Path: Delivered-To: freebsd-java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 923A7D35605 for ; Sun, 9 Apr 2017 05:31:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7AC042D5 for ; Sun, 9 Apr 2017 05:31:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7A0B2D35604; Sun, 9 Apr 2017 05:31:01 +0000 (UTC) Delivered-To: java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78043D35603 for ; Sun, 9 Apr 2017 05:31:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F3792D2 for ; Sun, 9 Apr 2017 05:31:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v395V0RS011609 for ; Sun, 9 Apr 2017 05:31:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: java@FreeBSD.org Subject: [Bug 218483] java/openjdk8 does not build in poudriere Date: Sun, 09 Apr 2017 05:31:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: riggs@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 05:31:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218483 --- Comment #2 from Thomas Zander --- (In reply to w.schwarzenfeld from comment #1) Possibly, thanks for the hint! I'll rebuild world and all my ports and in about 40 hours we probably know = more :-) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-java@freebsd.org Sun Apr 9 15:33:08 2017 Return-Path: Delivered-To: freebsd-java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA74ED35A31 for ; Sun, 9 Apr 2017 15:33:08 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B6EF3882 for ; Sun, 9 Apr 2017 15:33:08 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: by mailman.ysv.freebsd.org (Postfix) id B644DD35A30; Sun, 9 Apr 2017 15:33:08 +0000 (UTC) Delivered-To: java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5E05D35A2F for ; Sun, 9 Apr 2017 15:33:08 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail.eeeit.de (mail.eeeit.de [37.120.160.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 817D5881 for ; Sun, 9 Apr 2017 15:33:08 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from localhost (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mike@reifenberger.com) by mail.eeeit.de (Postfix) with ESMTPSA id 73ED46863 for ; Sun, 9 Apr 2017 17:32:59 +0200 (CEST) Received: from ppp-62-216-211-253.dynamic.mnet-online.de (ppp-62-216-211-253.dynamic.mnet-online.de [62.216.211.253]) by mail.eeeit.de (Horde Framework) with HTTPS; Sun, 09 Apr 2017 17:32:59 +0200 Date: Sun, 09 Apr 2017 17:32:59 +0200 Message-ID: <20170409173259.Horde.lkdNF63fvxbzp7yszXqRvsr@mail.eeeit.de> From: Michael Reifenberger To: java@freebsd.org Subject: openjdk8 with poudriere failes to configure User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 15:33:08 -0000 Hi, I'm using poudriere and FreeBSD11-stable ( both as of current). Compiling openjdk8 I get: ... ===> Configuring for openjdk8-8.121.13 Warning: You are using legacy autoconf cross-compilation flags. It is recommended that you use --openjdk-target instead. Running generated-configure.sh ./../../common/autoconf/generated-configure.sh: redirection error: cannot duplicate fd: Bad file descriptor ./../../common/autoconf/generated-configure.sh: line 561: 1: Bad file descriptor configure exiting with result code 1 ===> Script "../../configure" failed unexpectedly. Please report the problem to java@FreeBSD.org [maintainer] and attach the "/wrkdirs/usr/ports/java/openjdk8/work/openjdk/common/autoconf/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make: stopped in /usr/ports/java/openjdk8 root@11:amd64-default:/usr/ports/java/openjdk8 # more /wrkdirs/usr/ports/java/openjdk8/work/openjdk/common/autoconf/config.log /wrkdirs/usr/ports/java/openjdk8/work/openjdk/common/autoconf/config.log: No such file or directory ... Inside poudriere-jail: ... root@11:amd64-default:/usr/ports/java/openjdk8 # svnlite info Path: . Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head/java/openjdk8 Relative URL: ^/head/java/openjdk8 Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 438075 Node Kind: directory Schedule: normal Last Changed Author: jkim Last Changed Rev: 433180 Last Changed Date: 2017-02-02 21:28:22 +0000 (Thu, 02 Feb 2017) Any clues? Greetings --- mike Gruß --- Michael Reifenberger From owner-freebsd-java@freebsd.org Mon Apr 10 05:13:26 2017 Return-Path: Delivered-To: freebsd-java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B31C7D288B1 for ; Mon, 10 Apr 2017 05:13:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9C91A6ED for ; Mon, 10 Apr 2017 05:13:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9BE45D288B0; Mon, 10 Apr 2017 05:13:26 +0000 (UTC) Delivered-To: java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99D97D288AF for ; Mon, 10 Apr 2017 05:13:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83EF06EC for ; Mon, 10 Apr 2017 05:13:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3A5DPl1077559 for ; Mon, 10 Apr 2017 05:13:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: java@FreeBSD.org Subject: [Bug 218483] java/openjdk8 does not build in poudriere Date: Mon, 10 Apr 2017 05:13:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: riggs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 05:13:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218483 Thomas Zander changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |DUPLICATE --- Comment #3 from Thomas Zander --- It seems this was the problem. Updating world to a recent revision resolves= the issue. Thanks! *** This bug has been marked as a duplicate of bug 217846 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-java@freebsd.org Mon Apr 10 05:13:26 2017 Return-Path: Delivered-To: freebsd-java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8B61D288B5 for ; Mon, 10 Apr 2017 05:13:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id C2AC16EF for ; Mon, 10 Apr 2017 05:13:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C2092D288B3; Mon, 10 Apr 2017 05:13:26 +0000 (UTC) Delivered-To: java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFFB5D288B2 for ; Mon, 10 Apr 2017 05:13:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AFFAD6EE for ; Mon, 10 Apr 2017 05:13:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3A5DPl3077559 for ; Mon, 10 Apr 2017 05:13:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: java@FreeBSD.org Subject: [Bug 217846] Port: java/openjdk8 fails at the configure stage Date: Mon, 10 Apr 2017 05:13:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: riggs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 05:13:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217846 Thomas Zander changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |riggs@FreeBSD.org --- Comment #10 from Thomas Zander --- *** Bug 218483 has been marked as a duplicate of this bug. *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-java@freebsd.org Tue Apr 11 22:28:19 2017 Return-Path: Delivered-To: freebsd-java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D430D3A5FE for ; Tue, 11 Apr 2017 22:28:19 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 87DF36D5 for ; Tue, 11 Apr 2017 22:28:19 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from imac.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id D894C5646B; Tue, 11 Apr 2017 17:28:12 -0500 (CDT) Subject: Re: OpenJDK8 Thread.sleep will deadlock while turn down system date time. To: redraiment@gmail.com, freebsd-java@freebsd.org Cc: Konstantin Belousov References: <20170408070340.GD1788@kib.kiev.ua> From: Eric van Gyzen Message-ID: Date: Tue, 11 Apr 2017 17:28:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170408070340.GD1788@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 22:28:19 -0000 On 4/8/17 2:03 AM, Konstantin Belousov wrote: > On Fri, Apr 07, 2017 at 08:12:42PM -0700, ????????? wrote: >> Hi all, >> >> I found a Java process deadlock issue, and can be reproduced in FreeBSD >> 10.3 and 11.0 . >> >> My environment: >> >> * VirutalBox 5.1.16 r113841 on Mac OS X 10.12.4 >> * FreeBSD-11.0-RELEASE-amd64.vhd.xz >> >> Reproduction steps: >> >> 1. install openjdk8 >> >> ```sh >> pkg install openjdk8 >> ``` >> >> 2. Java source code >> >> ```java >> public class Main { >> public static void main(String[] args) { >> while (true) { >> System.out.println("tick"); >> Thread.sleep(3000); >> } >> } >> } >> ``` >> >> 3. Run java >> >> ```sh >> $ javac Main.java >> $ java Main >> tick >> tick >> ... >> ``` >> >> 4. Turn down system date time. >> >> ```sh >> $ date '+%Y-%m-%d %H:%M:%S' >> 20170408 11:09:11 >> $ date 201001010000 >> Fri Jan 1 00:00:00 CST 2010 >> ``` >> >> Then, the java process will hung. > Hang != deadlock, why do you claim that the process deadlocked. >> >> The issue will reproduce while turn "DOWN" the date time. It's OK while >> turn up the date time. > > 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@. (Thanks for the CC, Kostik.) Eric From owner-freebsd-java@freebsd.org Wed Apr 12 00:03:06 2017 Return-Path: Delivered-To: freebsd-java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A2CAD3A346 for ; Wed, 12 Apr 2017 00:03:06 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D426794C for ; Wed, 12 Apr 2017 00:03:05 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id v3BNtvWb037329; Tue, 11 Apr 2017 19:55:57 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 11 Apr 2017 19:55:57 -0400 (EDT) Date: Tue, 11 Apr 2017 19:55:57 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Eric van Gyzen cc: redraiment@gmail.com, freebsd-java@freebsd.org, Konstantin Belousov Subject: Re: OpenJDK8 Thread.sleep will deadlock while turn down system date time. In-Reply-To: Message-ID: References: <20170408070340.GD1788@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 00:03:06 -0000 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@. (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. You'd probably also want to check that whatever java.util.concurrent relies on, if different, also behaves similarly (monotonically). -- DE From owner-freebsd-java@freebsd.org Wed Apr 12 17:17:40 2017 Return-Path: Delivered-To: freebsd-java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1797ED3B5DE for ; Wed, 12 Apr 2017 17:17:40 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) by mx1.freebsd.org (Postfix) with ESMTP id 122E9C11; Wed, 12 Apr 2017 17:17:34 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: OpenJDK8 Thread.sleep will deadlock while turn down system date time. To: Daniel Eischen , Eric van Gyzen Cc: redraiment@gmail.com, Konstantin Belousov , freebsd-java@freebsd.org References: <20170408070340.GD1788@kib.kiev.ua> From: Jung-uk Kim Message-ID: <2349193f-568b-37f1-dcc5-7e0002046325@FreeBSD.org> Date: Wed, 12 Apr 2017 13:17:19 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cV6uTUg3GVSRShqXNSgmnjFCclB7rnd38" X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 17:17:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cV6uTUg3GVSRShqXNSgmnjFCclB7rnd38 Content-Type: multipart/mixed; boundary="JqwANXKv1kEpbKlP8nB59T9AmqT6F2xU5"; protected-headers="v1" From: Jung-uk Kim To: Daniel Eischen , Eric van Gyzen Cc: redraiment@gmail.com, Konstantin Belousov , freebsd-java@freebsd.org Message-ID: <2349193f-568b-37f1-dcc5-7e0002046325@FreeBSD.org> Subject: Re: OpenJDK8 Thread.sleep will deadlock while turn down system date time. References: <20170408070340.GD1788@kib.kiev.ua> In-Reply-To: --JqwANXKv1kEpbKlP8nB59T9AmqT6F2xU5 Content-Type: multipart/mixed; boundary="------------3CF86F02B7ADBD7F1FAAA726" Content-Language: en-GB This is a multi-part message in MIME format. --------------3CF86F02B7ADBD7F1FAAA726 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/11/2017 19:55, Daniel Eischen wrote: > On Tue, 11 Apr 2017, Eric van Gyzen wrote: >=20 >> 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.=20 >> 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@. (Thanks for the >> CC, Kostik.) >=20 > 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=3D6900441 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 --------------3CF86F02B7ADBD7F1FAAA726 Content-Type: text/x-patch; name="openjdk8.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="openjdk8.diff" Index: java/openjdk8/files/patch-hotspot_src_os_bsd_vm_os__bsd.cpp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- java/openjdk8/files/patch-hotspot_src_os_bsd_vm_os__bsd.cpp (nonexist= ent) +++ java/openjdk8/files/patch-hotspot_src_os_bsd_vm_os__bsd.cpp (working = copy) @@ -0,0 +1,245 @@ +--- hotspot/src/os/bsd/vm/os_bsd.cpp.orig 2017-04-12 17:03:59 UTC ++++ hotspot/src/os/bsd/vm/os_bsd.cpp +@@ -155,6 +155,7 @@ int (*os::Bsd::_getcpuclockid)(pthread_t + #endif + pthread_t os::Bsd::_main_thread; + int os::Bsd::_page_size =3D -1; ++pthread_condattr_t os::Bsd::_condattr[1]; +=20 + static jlong initial_time_count=3D0; +=20 +@@ -1076,12 +1077,15 @@ void os::Bsd::clock_init() { + void os::Bsd::clock_init() { + struct timespec res; + struct timespec tp; ++ _getcpuclockid =3D (int (*)(pthread_t, clockid_t *))dlsym(RTLD_DEFAUL= T, "pthread_getcpuclockid"); + if (::clock_getres(CLOCK_MONOTONIC, &res) =3D=3D 0 && + ::clock_gettime(CLOCK_MONOTONIC, &tp) =3D=3D 0) { + // yes, monotonic clock is supported + _clock_gettime =3D ::clock_gettime; ++ return; + } +- _getcpuclockid =3D (int (*)(pthread_t, clockid_t *))dlsym(RTLD_DEFAUL= T, "pthread_getcpuclockid"); ++ warning("No monotonic clock was available - timed services may " \ ++ "be adversely affected if the time-of-day clock changes"); + } + #endif +=20 +@@ -1117,7 +1121,7 @@ jlong os::javaTimeNanos() { + jlong os::javaTimeNanos() { + if (Bsd::supports_monotonic_clock()) { + struct timespec tp; +- int status =3D Bsd::_clock_gettime(CLOCK_MONOTONIC, &tp); ++ int status =3D ::clock_gettime(CLOCK_MONOTONIC, &tp); + assert(status =3D=3D 0, "gettime error"); + jlong result =3D jlong(tp.tv_sec) * (1000 * 1000 * 1000) + jlong(tp= =2Etv_nsec); + return result; +@@ -3721,6 +3725,25 @@ void os::init(void) { + Bsd::clock_init(); + initial_time_count =3D javaTimeNanos(); +=20 ++ // pthread_condattr initialization for monotonic clock ++ int status; ++ pthread_condattr_t* _condattr =3D os::Bsd::condAttr(); ++ if ((status =3D pthread_condattr_init(_condattr)) !=3D 0) { ++ fatal(err_msg("pthread_condattr_init: %s", strerror(status))); ++ } ++ // Only set the clock if CLOCK_MONOTONIC is available ++ if (Bsd::supports_monotonic_clock()) { ++ if ((status =3D pthread_condattr_setclock(_condattr, CLOCK_MONOTONI= C)) !=3D 0) { ++ if (status =3D=3D EINVAL) { ++ warning("Unable to use monotonic clock with relative timed-wait= s" \ ++ " - changes to the time-of-day clock may have adverse a= ffects"); ++ } else { ++ fatal(err_msg("pthread_condattr_setclock: %s", strerror(status)= )); ++ } ++ } ++ } ++ // else it defaults to CLOCK_REALTIME ++ + #ifdef __APPLE__ + // XXXDARWIN + // Work around the unaligned VM callbacks in hotspot's +@@ -4483,21 +4506,36 @@ void os::pause() { +=20 + static struct timespec* compute_abstime(struct timespec* abstime, jlong= millis) { + if (millis < 0) millis =3D 0; +- struct timeval now; +- int status =3D gettimeofday(&now, NULL); +- assert(status =3D=3D 0, "gettimeofday"); ++ + jlong seconds =3D millis / 1000; + millis %=3D 1000; + if (seconds > 50000000) { // see man cond_timedwait(3T) + seconds =3D 50000000; + } +- abstime->tv_sec =3D now.tv_sec + seconds; +- long usec =3D now.tv_usec + millis * 1000; +- if (usec >=3D 1000000) { +- abstime->tv_sec +=3D 1; +- usec -=3D 1000000; ++ ++ if (os::Bsd::supports_monotonic_clock()) { ++ struct timespec now; ++ int status =3D ::clock_gettime(CLOCK_MONOTONIC, &now); ++ assert_status(status =3D=3D 0, status, "clock_gettime"); ++ abstime->tv_sec =3D now.tv_sec + seconds; ++ long nanos =3D now.tv_nsec + millis * NANOSECS_PER_MILLISEC; ++ if (nanos >=3D NANOSECS_PER_SEC) { ++ abstime->tv_sec +=3D 1; ++ nanos -=3D NANOSECS_PER_SEC; ++ } ++ abstime->tv_nsec =3D nanos; ++ } else { ++ struct timeval now; ++ int status =3D gettimeofday(&now, NULL); ++ assert(status =3D=3D 0, "gettimeofday"); ++ abstime->tv_sec =3D now.tv_sec + seconds; ++ long usec =3D now.tv_usec + millis * 1000; ++ if (usec >=3D 1000000) { ++ abstime->tv_sec +=3D 1; ++ usec -=3D 1000000; ++ } ++ abstime->tv_nsec =3D usec * 1000; + } +- abstime->tv_nsec =3D usec * 1000; + return abstime; + } +=20 +@@ -4589,7 +4627,7 @@ int os::PlatformEvent::park(jlong millis + status =3D os::Bsd::safe_cond_timedwait(_cond, _mutex, &abst); + if (status !=3D 0 && WorkAroundNPTLTimedWaitHang) { + pthread_cond_destroy (_cond); +- pthread_cond_init (_cond, NULL) ; ++ pthread_cond_init (_cond, os::Bsd::condAttr()) ; + } + assert_status(status =3D=3D 0 || status =3D=3D EINTR || + status =3D=3D ETIMEDOUT, +@@ -4690,32 +4728,50 @@ void os::PlatformEvent::unpark() { +=20 + static void unpackTime(struct timespec* absTime, bool isAbsolute, jlong= time) { + assert (time > 0, "convertTime"); ++ time_t max_secs =3D 0; +=20 +- struct timeval now; +- int status =3D gettimeofday(&now, NULL); +- assert(status =3D=3D 0, "gettimeofday"); ++ if (!os::Bsd::supports_monotonic_clock() || isAbsolute) { ++ struct timeval now; ++ int status =3D gettimeofday(&now, NULL); ++ assert(status =3D=3D 0, "gettimeofday"); +=20 +- time_t max_secs =3D now.tv_sec + MAX_SECS; ++ max_secs =3D now.tv_sec + MAX_SECS; +=20 +- if (isAbsolute) { +- jlong secs =3D time / 1000; +- if (secs > max_secs) { +- absTime->tv_sec =3D max_secs; +- } +- else { +- absTime->tv_sec =3D secs; ++ if (isAbsolute) { ++ jlong secs =3D time / 1000; ++ if (secs > max_secs) { ++ absTime->tv_sec =3D max_secs; ++ } else { ++ absTime->tv_sec =3D secs; ++ } ++ absTime->tv_nsec =3D (time % 1000) * NANOSECS_PER_MILLISEC; ++ } else { ++ jlong secs =3D time / NANOSECS_PER_SEC; ++ if (secs >=3D MAX_SECS) { ++ absTime->tv_sec =3D max_secs; ++ absTime->tv_nsec =3D 0; ++ } else { ++ absTime->tv_sec =3D now.tv_sec + secs; ++ absTime->tv_nsec =3D (time % NANOSECS_PER_SEC) + now.tv_usec*10= 00; ++ if (absTime->tv_nsec >=3D NANOSECS_PER_SEC) { ++ absTime->tv_nsec -=3D NANOSECS_PER_SEC; ++ ++absTime->tv_sec; // note: this must be <=3D max_secs ++ } ++ } + } +- absTime->tv_nsec =3D (time % 1000) * NANOSECS_PER_MILLISEC; +- } +- else { ++ } else { ++ // must be relative using monotonic clock ++ struct timespec now; ++ int status =3D ::clock_gettime(CLOCK_MONOTONIC, &now); ++ assert_status(status =3D=3D 0, status, "clock_gettime"); ++ max_secs =3D now.tv_sec + MAX_SECS; + jlong secs =3D time / NANOSECS_PER_SEC; + if (secs >=3D MAX_SECS) { + absTime->tv_sec =3D max_secs; + absTime->tv_nsec =3D 0; +- } +- else { ++ } else { + absTime->tv_sec =3D now.tv_sec + secs; +- absTime->tv_nsec =3D (time % NANOSECS_PER_SEC) + now.tv_usec*1000= ; ++ absTime->tv_nsec =3D (time % NANOSECS_PER_SEC) + now.tv_nsec; + if (absTime->tv_nsec >=3D NANOSECS_PER_SEC) { + absTime->tv_nsec -=3D NANOSECS_PER_SEC; + ++absTime->tv_sec; // note: this must be <=3D max_secs +@@ -4795,15 +4851,19 @@ void Parker::park(bool isAbsolute, jlong + jt->set_suspend_equivalent(); + // cleared by handle_special_suspend_equivalent_condition() or java_s= uspend_self() +=20 ++ assert(_cur_index =3D=3D -1, "invariant"); + if (time =3D=3D 0) { +- status =3D pthread_cond_wait (_cond, _mutex) ; ++ _cur_index =3D REL_INDEX; // arbitrary choice when not timed ++ status =3D pthread_cond_wait (&_cond[_cur_index], _mutex) ; + } else { +- status =3D os::Bsd::safe_cond_timedwait (_cond, _mutex, &absTime) ;= ++ _cur_index =3D isAbsolute ? ABS_INDEX : REL_INDEX; ++ status =3D os::Bsd::safe_cond_timedwait (&_cond[_cur_index], _mutex= , &absTime) ; + if (status !=3D 0 && WorkAroundNPTLTimedWaitHang) { +- pthread_cond_destroy (_cond) ; +- pthread_cond_init (_cond, NULL); ++ pthread_cond_destroy (&_cond[_cur_index]) ; ++ pthread_cond_init (&_cond[_cur_index], isAbsolute ? NULL : os:= :Bsd::condAttr()); + } + } ++ _cur_index =3D -1; + assert_status(status =3D=3D 0 || status =3D=3D EINTR || + status =3D=3D ETIMEDOUT, + status, "cond_timedwait"); +@@ -4832,17 +4892,26 @@ void Parker::unpark() { + s =3D _counter; + _counter =3D 1; + if (s < 1) { +- if (WorkAroundNPTLTimedWaitHang) { +- status =3D pthread_cond_signal (_cond) ; +- assert (status =3D=3D 0, "invariant") ; ++ // thread might be parked ++ if (_cur_index !=3D -1) { ++ // thread is definitely parked ++ if (WorkAroundNPTLTimedWaitHang) { ++ status =3D pthread_cond_signal (&_cond[_cur_index]); ++ assert (status =3D=3D 0, "invariant"); + status =3D pthread_mutex_unlock(_mutex); +- assert (status =3D=3D 0, "invariant") ; +- } else { ++ assert (status =3D=3D 0, "invariant"); ++ } else { ++ // must capture correct index before unlocking ++ int index =3D _cur_index; + status =3D pthread_mutex_unlock(_mutex); +- assert (status =3D=3D 0, "invariant") ; +- status =3D pthread_cond_signal (_cond) ; +- assert (status =3D=3D 0, "invariant") ; +- } ++ assert (status =3D=3D 0, "invariant"); ++ status =3D pthread_cond_signal (&_cond[index]); ++ assert (status =3D=3D 0, "invariant"); ++ } ++ } else { ++ pthread_mutex_unlock(_mutex); ++ assert (status =3D=3D 0, "invariant") ; ++ } + } else { + pthread_mutex_unlock(_mutex); + assert (status =3D=3D 0, "invariant") ; Property changes on: java/openjdk8/files/patch-hotspot_src_os_bsd_vm_os__= bsd.cpp ___________________________________________________________________ Added: fbsd:nokeywords ## -0,0 +1 ## +yes \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: java/openjdk8/files/patch-hotspot_src_os_bsd_vm_os__bsd.hpp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- java/openjdk8/files/patch-hotspot_src_os_bsd_vm_os__bsd.hpp (nonexist= ent) +++ java/openjdk8/files/patch-hotspot_src_os_bsd_vm_os__bsd.hpp (working = copy) @@ -0,0 +1,63 @@ +--- hotspot/src/os/bsd/vm/os_bsd.hpp.orig 2017-04-12 15:33:50 UTC ++++ hotspot/src/os/bsd/vm/os_bsd.hpp +@@ -155,6 +155,13 @@ class Bsd { + #endif + } +=20 ++ // pthread_cond clock suppport ++ private: ++ static pthread_condattr_t _condattr[1]; ++ ++ public: ++ static pthread_condattr_t* condAttr() { return _condattr; } ++ + // Stack repair handling +=20 + // none present +@@ -220,7 +227,7 @@ class PlatformEvent : public CHeapObj { + protected: ++ enum { ++ REL_INDEX =3D 0, ++ ABS_INDEX =3D 1 ++ }; ++ int _cur_index; // which cond is in use: -1, 0, 1 + pthread_mutex_t _mutex [1] ; +- pthread_cond_t _cond [1] ; ++ pthread_cond_t _cond [2] ; // one for relative times and one for = abs. +=20 + public: // TODO-FIXME: make dtor private + ~PlatformParker() { guarantee (0, "invariant") ; } +@@ -250,10 +262,13 @@ class PlatformParker : public CHeapObj Delivered-To: freebsd-java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DAC7D3B388 for ; Wed, 12 Apr 2017 23:00:29 +0000 (UTC) (envelope-from kmisuth@ethome.sk) Received: from smtpout8.dnsserver.eu (smtpout8.dnsserver.eu [92.240.253.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 638A9253 for ; Wed, 12 Apr 2017 23:00:28 +0000 (UTC) (envelope-from kmisuth@ethome.sk) Received: from [92.240.253.67] (helo=smtp3s109.dnsserver.eu) by smtpout8.dnsserver.eu with esmtp (Exim 4.84 (FreeBSD)) (envelope-from ) id 1cyQsl-000PYC-O1 for freebsd-java@FreeBSD.org; Thu, 13 Apr 2017 00:36:59 +0200 Received: from [92.240.253.173] (helo=roundcube.dnsserver.eu) by smtp3s109.dnsserver.eu with esmtpa (Exim 4.83 (FreeBSD)) (envelope-from ) id 1cyQsl-000Duw-AP for freebsd-java@FreeBSD.org; Thu, 13 Apr 2017 00:36:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 13 Apr 2017 00:36:59 +0200 From: Kamil Misuth To: freebsd-java@FreeBSD.org Subject: State of Java NIO/KQueue Reply-To: kmisuth@ethome.sk Mail-Reply-To: kmisuth@ethome.sk Message-ID: <57b20c2254bea4d79844d133f362c129@pop3-imap.dnsserver.eu> X-Sender: kmisuth@ethome.sk User-Agent: Roundcube Webmail/1.2.0 X-SA-Exim-Connect-IP: 92.240.253.173 X-SA-Exim-Mail-From: kmisuth@ethome.sk X-SA-Exim-Scanned: No (on smtp3s109.dnsserver.eu); SAEximRunCond expanded to false X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 23:00:29 -0000 Greetings, I am trying out Apache Ignite on FreeBSD 11 with OpenJDK (7/8) and would really like to make it work well. Ignite uses NIO for inter node communication. When debugging I was able to confirm that KQueueSelectorImpl is used. For the purpose of testing I've used loopback interface with multiple aliases, however, for bigger payloads the communication seriously slows down from time to time and nodes would experience >3 second delay on reading side (I have no hard evidence collected yet). Interestingly, this would not happen for small payloads like serveral bytes. I went thought Ignite's selector loop and it looks OKish. I've tested my sample code on CentOS 7 with epoll selector using loopback in similar fashion and everything worked well even for larger payload with no hiccups. Some old Zookeeper docs would say NIO on FreeBSD is broken but then I also came across this https://issues.apache.org/jira/browse/ZOOKEEPER-1509 . So, my questions are: 1) How stable is KQueueSelectorImpl in current version of OpenJDK 8/7? 2) What would be the best way to start examining what's happening where for locating the possible bottle neck? 3) Could this be something buffer related? Thanks, Kamil From owner-freebsd-java@freebsd.org Thu Apr 13 10:28:34 2017 Return-Path: Delivered-To: freebsd-java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D099D3C2C2 for ; Thu, 13 Apr 2017 10:28:34 +0000 (UTC) (envelope-from redraiment@gmail.com) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E64C7B5F; Thu, 13 Apr 2017 10:28:33 +0000 (UTC) (envelope-from redraiment@gmail.com) Received: by mail-lf0-x244.google.com with SMTP id i3so6268445lfh.2; Thu, 13 Apr 2017 03:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=PHrkRNnpfifxtvMeRa39RL07mvtiYvAaYCAdC7gMYTg=; b=jfcM1EtToLB5lIsTWaJYZl996zqXp6tOmiRi4RJDSpLuHDZeYCirB2mP7JzbIu+snV uanQXwXqohNrL7+vqVTJ7tBWqXKsromqUFSqKODL2gMQBW6RtgTtme644Ox4snKXCH7b YZBdujGWbyoRBf8Vk7paKsDM4GlnbvgrMNyi+BqJ5aD9iXc8QY0C6ILV8T9L+ubV4c2I aDWQZdahkIK7FH+BuPI1NZcZwCfb0mcG+h6oNdxg/aAWjEDr9yfTxUn84myN9fSI8fy7 ulmgCiyqMLHDwxZ5FJ8IS3XR9JoJlgebQKcBH585cAul/bpB6uoKt67GN/thuRqrTkbX VUJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=PHrkRNnpfifxtvMeRa39RL07mvtiYvAaYCAdC7gMYTg=; b=pTrbmSYdiKHK0UgbVFC7TaZUfUjJcuMnXUSdafNJm7EAjWR3a/ssdxX2JEgeEq+FC1 Avp+Wl3LL4nkAousPNmVl+1/s0jJjcrH+by6HI+hho61kyZUb/C92OZWG1Qyws+tsalz u4GR399LOOOKecwWxD3YjrEiSD/AnEbrUWgZgwf8D/FjKDHcJU0Iz3AUiRDnASVwd566 8BemUgEnMtK43hRGzUy4t63I4wMsqbGAIBS6yoqESHcHD7jygRGFUWxA+F1HJxU0m3Jf k8q6oCgp+s0Qe720ePXxPB2MvDjXzfmqaX8hb10hNDhJMxBrZwT29IzGNb1BYc/9J2q3 tPxA== X-Gm-Message-State: AN3rC/5Si0ZMLAX5aBnGqbQ0UM10R38IIhLINmYFzOdaZJ9Z3AIkqMKE QvMcAKI1Ki/hJENkk3+beapP7JAYtQ== X-Received: by 10.46.71.206 with SMTP id u197mr711049lja.104.1492079310527; Thu, 13 Apr 2017 03:28:30 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 13 Apr 2017 06:28:29 -0400 From: =?UTF-8?B?5byg5rO96bmP?= In-Reply-To: <2349193f-568b-37f1-dcc5-7e0002046325@FreeBSD.org> References: <20170408070340.GD1788@kib.kiev.ua> <2349193f-568b-37f1-dcc5-7e0002046325@FreeBSD.org> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 13 Apr 2017 06:28:29 -0400 Message-ID: Subject: Re: OpenJDK8 Thread.sleep will deadlock while turn down system date time. To: Jung-uk Kim , Eric van Gyzen , Daniel Eischen Cc: Konstantin Belousov , freebsd-java@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 10:28:34 -0000 I apply the patch and reinstall from ports, it works well for me now. Thanks Kim! thanks everyone! =E5=8F=91=E4=BB=B6=E4=BA=BA: Jung-uk Kim =E5=9B=9E=E5=A4=8D: Jung-uk Kim =E6=97=A5=E6=9C=9F: 2017=E5=B9=B44=E6=9C=8813=E6=97=A5 at =E4=B8=8A=E5=8D= =881:17:41 =E8=87=B3: Daniel Eischen , Er= ic van Gyzen =E6=8A=84=E9=80=81: redraiment@gmail.com , Konstantin Belousov , freebsd-java@freebsd.org =E4=B8=BB=E9=A2=98: Re: OpenJDK8 Thread.sleep will deadlock while turn dow= n system date time. 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@. (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=3D6900441 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