RE: GC_data_start

["Boehm, Hans" <hboehm at exch dot hpl dot hp dot com>]

I'm willing to put the /proc code in the "official" version for now,
assuming that's OK with you.  I would still prefer to see __data_start back,
if anyone is in a position to lobby for it.  At a minimum, its prsence
should be consistent across platforms.

My concern about the "brittleness" of the code stems from the dependency on
the formatting in the maps file and the dependency on the ordering of
various segments, and on the fact that each segment corresponds directly to
a single mapping.  Hopefully all of those are stable, but I would have
thought the same about __data_start.

It's possible to use your code to get the stack base.  But I believe it's
slower than the current code because of fscanf parsing.  I'm not sure that
it doesn't matter, since I suspect it will eventually have to be invoked
once per thread creation.

Hans  

-----Original Message-----
From: Jeff Sturm [mailto:jsturm@sigma6.com]
Sent: Tuesday, November 16, 1999 1:02 PM
To: Boehm, Hans
Cc: java-discuss@sourceware.cygnus.com
Subject: Re: GC_data_start


"Boehm, Hans" wrote:
> I don't recall seeing the /proc-based code before.  My version 4.13 used
> __data_start.  This used to be defined by the linker or glibc, but
> disappeared somewhere along the way.  The GC_find_limit approach was put
in
> as a replacement.  But I agree that it has problems.

__data_start began to disappear somewhere around the RH6.0 releases.  I
don't know why and haven't investigated closely.  Ideally we could fix
it but since it's already broken on hundreds of ftp sites and zillions
of CD-ROMs in distribution it's almost more palatable to just implement
a workaround...

> My only problem with the /proc-based solution here is that it's a fair
> amount of fairly brittle code to accomplish something that should be
> trivial, and used to be trivial.  (Reading the stack base, in contrast, is
a
> small amount of slightly less brittle, and completely different, code.) I
> would prefer to see glibc or ld consistently define a symbol that maps to
> the beginning of the data segment.  As far as I can tell, ld does this on
> Linux/X86, but not on some other platforms.  Does anybody know why?  Any
> chance of getting this fixed?

Maybe it could be done with less code, I don't know... I originally
wrote the function to see just how much I could extract from /proc about
the mapped segments.  It turns out that you can easily and reliably
detect the stack (at least for single-threaded apps) and the text/data
segments of the main executable and all shared libraries.

As to brittleness, it should work on all recent Linux distributions
regardless of architecture, and continue to work as long as
/proc/%d/maps is available... it obviously won't work if somebody has
/proc unmounted, but that really shouldn't ever happen.  I was a little
hopeful it could somehow be merged with the stackbottom-detecting code,
and maybe even the library stuff in dyn_load.c, which uses some strange
code indeed.

I realize it's not too pretty, that's why I posted a comment instead of
a patch... yet while the current code is broken I feel quite motivated
to fix it.  Better ideas are welcome.

Maybe we can fix ld, and add a FAQ entry "...fix your ld..." but I fear
that sort of solution will only help to slow the adoption of gcj on
Linux.

-- 
Jeff Sturm
jsturm@sigma6.com