From owner-freebsd-java Sun Feb 1 22:05:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA08739 for java-outgoing; Sun, 1 Feb 1998 22:05:46 -0800 (PST) (envelope-from owner-freebsd-java@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA08732 for ; Sun, 1 Feb 1998 22:05:45 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id XAA12181; Sun, 1 Feb 1998 23:05:44 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id XAA26684; Sun, 1 Feb 1998 23:05:41 -0700 Date: Sun, 1 Feb 1998 23:05:41 -0700 Message-Id: <199802020605.XAA26684@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "SIVA SANKARAN" Cc: freebsd-java@FreeBSD.ORG Subject: Re: TimeSlicing in JVM In-Reply-To: <199802020552.AAA08800@dwarpal.in.oracle.com> References: <199802020552.AAA08800@dwarpal.in.oracle.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe java" > In the standard JDK code, for Solaris Green-threads the 'Timeslicing' > (i.e if more than one thread, runs at the same priority using Round-Robin > method of scheduling) is disabled. Yes, that is true (for many reasons). > Therefore other threads, waiting in the > Runnable Queue of the same priority of the currently running thread has to > wait, till the running thread finishes or yields. Right again. > The code is in > src/freebsd/java/green_threads/src/clock.c . The function is timeSlicer. But > the variable > TimeSlice is initialized to 0 (=> no TimeSlice ) BTW, this file is an exact copy of the solaris code. (It's a symlink in the FreeBSD-JDK development tree.) > Is this the desired behavior. Can I make Round-Robin fashion of > scheduling for > equal priority threads. You can try, but how do you propose 'interrupting' a running thread? Remember, everything runs in a single process space (w/out kernel threads), and that if a running thread is in a system call there is no way to pre-empt it reliably. Because of this 'feature', I suspect the authors gave up trying to implement a fair-scheduling algorithm, because it would not deterministic enough due to the above issue (and other similar to it). One of the really nasty things in the current green-thread port which exists on all *nix platforms which don't use kernel threads is that a single thread can sit in a tight loop and never let go, which means that if you have one errant thread your entire VM is hosed. This is a *bad* thing, but I don't see any way around it w/out kernel support. Nate