[fedora-java] rssowl: libgcj bugs that need fixing for it torun

[Boehm, Hans]

[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 at redhat.com] 
> Sent: Thursday, July 28, 2005 7:47 AM
> To: tromey at 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
> 
> 
>