[I missed the beginning of this thread initially.]

I'm actually trying to work on some of these issues. Some status:

1) I'm currently hacking on the /proc/self/maps reading code that's already in the GC. The current code actually broke with a kernel change in August 2003 which changed the file format on 64-bit architectures. Unfortunately it didn't break blatantly enough for anyone to notice until now. I have a patch that should probably be integrated into gcj, but it needs a bit more mileage on it.

2) Reading /proc/self/maps reliably in a multithreaded environment seems hard. I'm still trying to understand this better, but there seems to be a design flaw here. Reads can return short, meaning that you don't necessarily get a consistent picture. And AFAICT, both nptl and linuxthreads unmap thread stacks after the thread becomes invisible to the user, so there is no way you can deal with this by user level synchronization. The mappings can change even if all threads that haven't exited are stopped. I currently believe that /proc/self/maps can only shrink asynchronously, so it might be possible to address this by reading it twice.

3) I have code in my gc7 tree to intercept pthread_create as suggested here. My immediate goal is to make it possible to use the gc as a preloadable malloc replacement, even in the multithreaded case. (This seems to require /proc/self/maps, since the dynamic loader seems to have its own malloc, and the objects it allocates point to objects allocated with the later malloc.) I think this is getting close to working, but I'm not quite there.

4) Gc7 (even the released, but very experimental alpha3 version) has a thread registration interface. That's probably a better solution for some of the problems here. (The implementation behind this interface is currently severely lacking in places. But at least there's an interface.)

5) My general plan is to get gc7 slightly more stable, and then set up CVS access to it.

Hans

-----Original Message----- From: Anthony Green [mailto:green@redhat.com] Sent: Thursday, July 28, 2005 7:47 AM To: tromey@redhat.com Cc: Boehm, Hans; Discussion list for java related Fedora development Subject: Re: [fedora-java] rssowl: libgcj bugs that need fixing for it torun

On Wed, 2005-07-27 at 12:16 -0600, Tom Tromey wrote:

...

This seems like a reasonable approach when libgcj is linked

into the

...

resulting executable. But how can it work if we dlopen()

libgcj and

...

then attach a previously-existing thread?

It can't; this only solves the problem reported. We could force tricky programmers to do thread registrations themselves. The PyLucene people probably solved this in some way.

...

I was wondering if there was some /proc-reading approach

(or something

...

like that) that we could use to find information about threads.

Well, I'm guessing that the "[stack]" line /proc/<pid>/task/<pid>/maps describes the extent of each stack. Is this an interface we can depend on over all Linux implementations? (isn't /proc optional during kernel configuration?)

AG