Date: Thu, 6 Jun 2002 08:53:35 -0700 (PDT) From: "Robert F. Ross" <rross@recourse.com> To: Bill Huey <billh@gnuppy.monkey.org> Cc: Jan Grant <Jan.Grant@bristol.ac.uk>, "Robert F. Ross" <rross@recourse.com>, freebsd-java@freebsd.org Subject: Re: green vs. native threads Message-ID: <Pine.GSO.4.21.0206060850560.1002-100000@recourse.com> In-Reply-To: <20020606104119.GA5028@gnuppy.monkey.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is on 4.5-RELEASE that I'm seeing these issues. I'm not sure what the libc_r signal debugging stuff is, but truss does't show anything at all happening in the process (even when I wait for longer than the select() timeouts). It looks like it's in an infinite loop of some sort without any syscalls. Using kqueue in the JNI-invoked code would be a pain since it's supposed to be portable code. Why would the JVM need its own special libc_r? Robert Ross Senior Software Engineer Recourse Technologies, Inc. On Thu, 6 Jun 2002, Bill Huey wrote: > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.21.0206060850560.1002-100000>