This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: libgcj and the NPTL posix threads implementation
- From: Anthony Green <green at redhat dot com>
- To: "Boehm, Hans" <hans dot boehm at hp dot com>
- Cc: "'Michael Koch'" <konqueror at gmx dot de>, java at gcc dot gnu dot org
- Date: Fri, 27 Feb 2004 09:45:51 -0800
- Subject: RE: libgcj and the NPTL posix threads implementation
- Organization: Red Hat, Inc.
- References: <0C3EFB691636964BBF914AE56AE83A89501F95@hplex4.hpl.hp.com>
On Fri, 2004-02-27 at 09:23, Boehm, Hans wrote:
> I'm not quite sure what the best replacement is, though. You were suggesting
> just using the segment register directly?
Yes, that's what I'm thinking.
> That avoids the dynamic library
> call, and is no doubt the fastest, though a bit ugly.
This seems like a great place to sacrifice simplicity for performance.
Some of our benchmark results are ugly too! :-)
> On the other hand, the recursive mutex issue is different.
> With hash synchronization, _Jv_MonitorEnter should not invoke any
> pthreads routines (except possibly pthread_self()) on the fast path.
> Thus I think this should be a very minor optimization. Since the current
> code is no doubt more portable, I'm not sure it's worth it. If pthread_mutex_lock
> shows up near the top of a profile, I'd like to know about it.
Ok. I've been planning on running oprofile for a while now, but I'm
waiting for a kernel fix before it will work on my h/w.
AG
--
Anthony Green <green@redhat.com>
Red Hat, Inc.