From owner-freebsd-java Thu Jun 6 3:41:36 2002 Delivered-To: freebsd-java@freebsd.org Received: from gnuppy.monkey.org (wsip68-15-8-100.sd.sd.cox.net [68.15.8.100]) by hub.freebsd.org (Postfix) with ESMTP id D730337B401 for ; Thu, 6 Jun 2002 03:41:33 -0700 (PDT) Received: from billh by gnuppy.monkey.org with local (Exim 3.35 #1 (Debian)) id 17Fuhj-0001JI-00; Thu, 06 Jun 2002 03:41:19 -0700 Date: Thu, 6 Jun 2002 03:41:19 -0700 To: Jan Grant Cc: "Robert F. Ross" , freebsd-java@freebsd.org, Bill Huey Subject: Re: green vs. native threads Message-ID: <20020606104119.GA5028@gnuppy.monkey.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Jun 06, 2002 at 10:36:41AM +0100, Jan Grant wrote: > > Has anyone seen either of these issues or have any idea what may be > > causing them? Turn on the signal debugging stuff libc_r and see if it's trying to deliver a SIGSEGV in an infinite loop. > Is this on -stable? I've seen thread-enabled applications consume large > amounts of CPU inside the libc_r. My guess was that the "blocking" calls > like select are being faked by the thread library - which is fine if > they've got other work to do - but if everything is waiting on a > blocking call the whole caboodle goes into a busy loop waiting on one of > the events you're "blocking" on. > > (Compiling apache with threading on -stable exhibited this behaviour.) > > I've no idea how or at what level the jvm interacts with the native > threading system - haven't looked, don't particularly want to. Blocking threads are converted into async IO event within a select() call. I would expect that to generate a lot of CPU suck unless you have zillions of threads. Moving to kqueue might fix the scalability problem. KSEs certainly would fix it since select() would be replaced by some other IO wake mechanism. I'm not sure what the problem is here. It could be a number of nasty things. Also -native has problems with fringe wait logic in pthread_cond_timewait() not suspending properly. Dan Eischen recent made changes to libc_r under -current (?) to fix that problem. It's something I've whined about many times on this list. BTW, I'm trying to get a person to do a special libc_r just for native threading (from -current ?) in the JVM, while I'm going to take a rest for a while on the issues. We'll see what happens. Good luck. ;) bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message