From owner-freebsd-java Thu Jun 6 15:45:40 2002 Delivered-To: freebsd-java@freebsd.org Received: from recourse.com (mail.recourse.com [206.171.10.25]) by hub.freebsd.org (Postfix) with ESMTP id 9F88137B40D for ; Thu, 6 Jun 2002 15:45:09 -0700 (PDT) Received: from recourse.com (localhost [127.0.0.1]) by recourse.com (8.12.1/8.12.1) with ESMTP id g56MiqVI015275; Thu, 6 Jun 2002 15:44:52 -0700 (PDT) Received: from localhost (rross@localhost) by recourse.com (8.12.1/8.12.1/Submit) with ESMTP id g56MipcX015272; Thu, 6 Jun 2002 15:44:52 -0700 (PDT) Date: Thu, 6 Jun 2002 15:44:51 -0700 (PDT) From: "Robert F. Ross" X-Sender: rross@recourse.com To: Bill Huey Cc: "Robert F. Ross" , Jan Grant , freebsd-java@freebsd.org Subject: Re: green vs. native threads In-Reply-To: <20020606221014.GA2514@gnuppy.monkey.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Ah. The process appears to actually function and do everything it's supposed to, so I don't think it's the SIGSEGV issue (I'm still not sure what the libc_r signal debugging stuff is, I don't debug stuff on freebsd often). The most likely thing from the replies I've seen is that the pthread library is busywaiting during select() or something. It does everything it's supposed to but tends to burn 100% cpu even when it shouldn't need to. Robert Ross Senior Software Engineer Recourse Technologies, Inc. On Thu, 6 Jun 2002, Bill Huey wrote: > On Thu, Jun 06, 2002 at 08:53:35AM -0700, Robert F. Ross wrote: > > 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 > > The switch to kqueue would be within libc_r, not the JVM itself. > > The reason why I thought it was a signal problem was that it looked like > it was stopped in the signal delivery code. It could be trying to deliver > a SIGSEGV to a corrupted stack and therefore generating another SEGSIGV, > hence creating an infinite loop. That's why I asked for you to turn on > the signal debugging stuff. > > > since it's supposed to be portable code. Why would the JVM need its own > > special libc_r? > > Bugs in libc_r. > > bill > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message