From owner-freebsd-java Mon Feb 2 09:58:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA01519 for java-outgoing; Mon, 2 Feb 1998 09:58:44 -0800 (PST) (envelope-from owner-freebsd-java@FreeBSD.ORG) Received: from damon.com (ycqsERAYZ4f6eC/MQvK+a8xq9HTDmoHf@damon.com [207.170.114.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA01508 for ; Mon, 2 Feb 1998 09:58:36 -0800 (PST) (envelope-from dap@damon.com) Received: (from dap@localhost) by damon.com (8.8.7/8.8.7) id LAA06618; Mon, 2 Feb 1998 11:54:09 -0600 (CST) (envelope-from dap) From: Damon Permezel Message-Id: <199802021754.LAA06618@damon.com> Subject: Re: TimeSlicing in JVM In-Reply-To: <199802021623.KAA06394@damon.com> from Damon Permezel at "Feb 2, 98 10:23:52 am" To: dap@damon.com (Damon Permezel) Date: Mon, 2 Feb 1998 11:54:09 -0600 (CST) Cc: dap@damon.com, jb@cimlogic.com.au, nate@mt.sri.com, 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" "Damon Permezel sez: " > "Damon Permezel sez: " > > "Damon Permezel sez: " > > > "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. > > > > Silly me! > > You can just use: > > > > java -ts100 .... > > > > to turn on time slicing with green threads. > > From an initial sniff, I see that there is not a timeslicer thread running. > > > I think you mean "now", rather than not, no? > Correct, but I have observed applications which used to work stop. For example, using the current non-fractal hallucinations, patched to not call yield: LD_LIBRARY_PATH=lib java -ts100 damon.dap.NFH.NFH -w 128 never displays the initial window, and the idle thread is running. If I change it to `-ts3000' to give it a chance to get the initial window up, it runs OK, but what use is a 3 second time slice? Thus, there are bugs which turning timeslice on aggravates. The sun/awt code has all these locks which think they are not recursively obtainable, but which are clearly recursive. This may be at least one source of these problems.