From owner-freebsd-java  Mon Feb  2 08:08:34 1998
Return-Path: <owner-freebsd-java@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id IAA19047
          for java-outgoing; Mon, 2 Feb 1998 08:08:34 -0800 (PST)
          (envelope-from owner-freebsd-java@FreeBSD.ORG)
Received: from damon.com (wQZi/WS6MAgkFCp0bC1209Lj2JfWPhdZ@damon.com [207.170.114.1])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA19036
          for <freebsd-java@FreeBSD.ORG>; Mon, 2 Feb 1998 08:08:28 -0800 (PST)
          (envelope-from dap@damon.com)
Received: (from dap@localhost)
	by damon.com (8.8.7/8.8.7) id KAA06305;
	Mon, 2 Feb 1998 10:03:25 -0600 (CST)
	(envelope-from dap)
From: Damon Permezel <dap@damon.com>
Message-Id: <199802021603.KAA06305@damon.com>
Subject: Re: TimeSlicing in  JVM
In-Reply-To: <199802020636.XAA26813@mt.sri.com> from Nate Williams at "Feb 1, 98 11:36:21 pm"
To: nate@mt.sri.com (Nate Williams)
Date: Mon, 2 Feb 1998 10:03:25 -0600 (CST)
Cc: jb@cimlogic.com.au, nate@mt.sri.com,
        SSANKARA.IN.oracle.com.ofcmail@in.oracle.com, freebsd-java@FreeBSD.ORG,
        java-port@mt.sri.com (Java Port)
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"

On a similar thread, what do folks feel about the implementation of
yield?  With non-preemptive threads, yield does:

(from sysThreadYield()):

    if (runnable_queue && runnable_queue->priority == self->priority) {

	... yields to threads only of the same priority.

This means I cannot write a CPU hog function, run it in a low priority
thread, and call yield() periodicially, expecting the higher pri runnables
to get some CPU.

This forces me to run my CPU hog at "normal" priority, and means that
the async garbage collector thread will never run, unless I also arrange to
call it from the CPU hog function.

I would have preferred to have the hog run at THREAD_MIN (or whatever it was
called) which is where the async GC runs, and have it be able to yield
the CPU to the user interface threads, and other threads, as well as the GC.
(I know that this doesn't really solve the GC issue.)

I haven't experimented with changing it to:

    if (runnable_queue && runnable_queue->priority >= self->priority) {

as it is often easier (and "better") to work around these issues in my app,
but I believe such a change is warranted.