From owner-freebsd-java  Mon Feb  2 08:12:31 1998
Return-Path: <owner-freebsd-java@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id IAA20104
          for java-outgoing; Mon, 2 Feb 1998 08:12:31 -0800 (PST)
          (envelope-from owner-freebsd-java@FreeBSD.ORG)
Received: from damon.com (GmkIC8rY3a0zZznPF9HjQ6CRu67rI9EA@damon.com [207.170.114.1])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA20089
          for <freebsd-java@FreeBSD.ORG>; Mon, 2 Feb 1998 08:12:14 -0800 (PST)
          (envelope-from dap@damon.com)
Received: (from dap@localhost)
	by damon.com (8.8.7/8.8.7) id KAA06331;
	Mon, 2 Feb 1998 10:11:27 -0600 (CST)
	(envelope-from dap)
From: Damon Permezel <dap@damon.com>
Message-Id: <199802021611.KAA06331@damon.com>
Subject: Re: TimeSlicing in  JVM
In-Reply-To: <199802020649.RAA00688@cimlogic.com.au> from John Birrell at "Feb 2, 98 05:49:15 pm"
To: jb@cimlogic.com.au (John Birrell)
Date: Mon, 2 Feb 1998 10:11:27 -0600 (CST)
Cc: nate@mt.sri.com, jb@cimlogic.com.au,
        SSANKARA.IN.oracle.com.ofcmail@in.oracle.com, freebsd-java@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-java@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org
X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe java"

"John Birrell sez: "
> Nate Williams wrote:
> > I also remember thinking seriously about this problem after reading a
> > Java threads book, and they brought up another point that I can't recall
> > right now that was also one of those 'syscall' types of problems.  If I
> > remember or find it I'll send something to the list.
> 
> It might be a scheduler issue. Like the one where a lower priority
> thread locks a resource that a higher priority thread needs, but the
> lower priority thread can't get enough CPU time to finish using the
> resource. libc_r deals with this by using an incremental priority
> that is reset when a thread gets to run, but is incremented the
> longer it is ready to run but prevented from running. Eventually
> the lower priority thread has a higher effective priority and gets
> to see its name in lights.
> 

The green_threads scheduler has priority inversion.
Not sure if it works.  This is one of the issues of turning on time slicing.
Perhaps there were many good reasons why it is off for green_threads....

I guess one of us should scrutinize the code, see if we really think
turning on the timeslicing will work (at the basic level, without too
much associated hacking) and then turn it on.

If it looks like it works, then we should consider dropping the code into the
official release, initially requiring the setting of a resource or an
environment var to enable timeslice.

I have a basic test for this, and I am motifated, so I volunteer....