From owner-freebsd-java Thu Aug 8 7:48: 3 2002 Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94E0137B400 for ; Thu, 8 Aug 2002 07:48:02 -0700 (PDT) Received: from turing.morons.org (turing.morons.org [209.237.229.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5B6643E86 for ; Thu, 8 Aug 2002 07:48:01 -0700 (PDT) (envelope-from freebsd@spatula.net) Received: by turing.morons.org (Postfix, from userid 1001) id 7B9AAAB40; Thu, 8 Aug 2002 07:48:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turing.morons.org (Postfix) with ESMTP id 7A9B6AB36 for ; Thu, 8 Aug 2002 07:48:01 -0700 (PDT) Date: Thu, 8 Aug 2002 07:48:01 -0700 (PDT) From: Nick Johnson X-X-Sender: spatula@turing.morons.org To: freebsd-java@freebsd.org Subject: Thread.sleep implementation Message-ID: <20020808074233.T13773-100000@turing.morons.org> X-what-happen: someone set up us the bomb X-Message-Flags: Spatula MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've noticed that in threads which are trying to make locks or wait to retry on some failure condition, the JVM tends to suddenly begin using tons of CPU, despite the presense of a Thread.sleep() call inside the loop. What seems to also happen is starvation of the other threads, almost as though Thread.sleep were implemented as a busy loop (?). I'll try to come up with a test case for this. I bring it up here in case someone closer to the JVM's internals might know what I'm talking about... Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message