Date: Thu, 6 Jun 2002 10:36:41 +0100 (BST) From: Jan Grant <Jan.Grant@bristol.ac.uk> To: "Robert F. Ross" <rross@recourse.com> Cc: freebsd-java@freebsd.org Subject: Re: green vs. native threads Message-ID: <Pine.GSO.4.44.0206061031510.29324-100000@mail.ilrt.bris.ac.uk> In-Reply-To: <Pine.GSO.4.21.0206050940450.1002-100000@recourse.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 5 Jun 2002, Robert F. Ross wrote: > On the suggestion from people here about using native threads instead of > green threads I tried running the VM with -native. I never managed to get > select() or poll() behaving right through JNI with green threads. With > native threads, they appear to behave exactly as they should. The problem > is, with native threads my java process eats 100% CPU. When I try to > attach with gdb to see where this is happening, it appears to always > attach with a backtrace of: ... > Has anyone seen either of these issues or have any idea what may be > causing them? 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. jan -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk ...You're visualising the _duck_ taped over my _mouth_..? 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.44.0206061031510.29324-100000>