libgcj and the NPTL posix threads implementation

Fri Feb 27 18:15:00 GMT 2004

> -----Original Message-----
> From: Anthony Green [mailto:green@redhat.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. 
Agreed. I have no objection.
>> > 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.
>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. Unlike oprofile, you don't get system-wide
or kernel information, but it should handle threads
and dynamic libraries. I've had reasonable luck with gcj-generated code.
In fact, it was part of the motivation for building it.
The current version has some performance issues with
very long profiling runs, but I tend not to have the patience for those
anyway.
Hans