From owner-freebsd-java@FreeBSD.ORG Mon Sep 17 04:57:48 2007 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E729816A468 for ; Mon, 17 Sep 2007 04:57:48 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D198F13C45D for ; Mon, 17 Sep 2007 04:57:48 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id BC3681A4D7C; Sun, 16 Sep 2007 21:57:48 -0700 (PDT) Date: Sun, 16 Sep 2007 21:57:48 -0700 From: Alfred Perlstein To: Nick Johnson Message-ID: <20070917045748.GU79417@elvis.mu.org> References: <46EC1B55.4060202@FreeBSD.org> <200709152250.50879.kurt@intricatesoftware.com> <20070917005912.GT79417@elvis.mu.org> <20070916182507.W82369@turing> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070916182507.W82369@turing> User-Agent: Mutt/1.4.2.3i Cc: freebsd-java@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 04:57:49 -0000 * Nick Johnson [070916 18:30] wrote: > On Sun, 16 Sep 2007, Alfred Perlstein wrote: > > > > Thread.yield() could first lower the current thread's priority to > > > the next used priority and then yield, raising the priority back after > > > the yield. This isn't perfect, there are race conditions, the next > > > highest priority thread(s) could be blocked and not runnable, etc. > > > Maybe just lowering the priority to min or default priority would work > > > well enough. > [snip] > > I think your suggestion about temporarily lowering priority > > makes sense. > > That sounds sane to me... if the JVM also keeps track of the fact of > another thread's having executed, one could lower the priority of the > thread to some minimum value, and then only raise it again once another > thread managed to execute... it seems like that would roughly recreate the > behaviour they're looking for. > > (Although maybe just dropping it to the minimum possible priority and then > restoring the priority the next time the thread ran would be sufficient to > prevent the deadlock? Perhaps an absolutely minimum priority value could > be reserved for threads from which this yielding behaviour was needed so > in case there were other threads that also had a low priority, they'd > still have a higher priority than the thread being asked to yield?) You second suggestion makes more sense as I would guess that the intent is to lower the priority until the next quantum. The second part of your second suggestion is not 100% needed (although it may be helpful) as the scheduler will appopriately run another thread and they will then contend at that lower level. -- - Alfred Perlstein