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: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: "'Anthony Green'" <green at redhat dot com>,"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: Mon, 1 Mar 2004 14:28:29 -0800
- Subject: RE: libgcj and the NPTL posix threads implementation
I'm surprised that pthread mutexes are that significant. That may suggest a
configuration problem.
The collector does use pthread mutexes in the gcj configuration. But that's because
thread-local allocation is enabled, and the small object allocations should not
normally involve locking.
Is this a benchmark that allocates primarily larger objects? The maximum size
for thread-local allocation is fairly small (512bytes?). Or are you creating
lots of short-lived threads?
Hans
> -----Original Message-----
> From: Anthony Green [mailto:green@redhat.com]
> Sent: Friday, February 27, 2004 12:18 PM
> To: Boehm, Hans
> Cc: 'Michael Koch'; java@gcc.gnu.org
> Subject: RE: libgcj and the NPTL posix threads implementation
>
>
> On Fri, 2004-02-27 at 10:15, Boehm, Hans wrote:
> > You might try http://www.hpl.hp.com/research/linux/qprof .
> I'm biased,
> > but a design goal was to build a quick-and-dirty profiler
> that's trivial
> > to install and run.
>
> Just tried it, and it's pretty neat.
>
> pthread mutexes do show up in my benchmark at about 15% of the time.
> They are used extensively by the GC. Perhaps we could your light
> weight locks here as well.
>
> AG
>
> --
> Anthony Green <green@redhat.com>
> Red Hat, Inc.
>