[gclist] Boehm gc with STL from gcc 2.95.2?

[Benjamin Geer]

Thanks for the clarification.  I did a test with list<Foo*, gc_alloc>
using gc5.0alpha6 and new_gc_alloc.h (where Foo is derived from
gc_cleanup), and it seems to work fine.

However, when building gc5.0alpha6, `make test' hangs if I use
-DREDIRECT_MALLOC.  This problem didn't occur with gc5.0alpha4.
Here's the output of `make test' (still hung after about 5 minutes):

---begin included output---
/usr/local/src/gc# make test
cc  -O -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DALL_INTERIOR_POINTERS -DSILENT -DLINUX_THREADS -D_REENTRANT -DOPERATOR_NEW_ARRAY -DREDIRECT_MALLOC=GC_malloc_uncollectable -o setjmp_test ./setjmp_t.c
./setjmp_t.c: In function `nested_sp':
./setjmp_t.c:58: warning: function returns address of local variable
./setjmp_test
This appears to be a I386 running LINUX
Stack appears to grow down, which is the default.
A good guess for STACKBOTTOM on this machine is 0xc0000000.
Note that this may vary between machines of ostensibly
the same architecture (e.g. Sun 3/50s and 3/80s).
On many machines the value is not fixed.
A good guess for ALIGNMENT on this machine is 4.
Generic mark_regs code may work
./gctest
---end included output---

Without -DREDIRECT_MALLOC, everything seems to be fine (the following
output is produced in about 15 seconds, with no noticable pause after
`./gctest'):

---begin included output---
/usr/local/src/gc# make test
cc  -O -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DALL_INTERIOR_POINTERS -DSILENT -DLINUX_THREADS -D_REENTRANT -DOPERATOR_NEW_ARRAY -o setjmp_test ./setjmp_t.c
./setjmp_t.c: In function `nested_sp':
./setjmp_t.c:58: warning: function returns address of local variable
./setjmp_test
This appears to be a I386 running LINUX
Stack appears to grow down, which is the default.
A good guess for STACKBOTTOM on this machine is 0xc0000000.
Note that this may vary between machines of ostensibly
the same architecture (e.g. Sun 3/50s and 3/80s).
On many machines the value is not fixed.
A good guess for ALIGNMENT on this machine is 4.
Generic mark_regs code may work
./gctest
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Completed 3 tests
Finalized 6615/6615 objects - finalization is probably ok
Total number of bytes allocated is 185728428
Final heap size is 9318400 bytes
Collector appears to work
Completed 457 collections
cc  -O -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DALL_INTERIOR_POINTERS -DSILENT -DLINUX_THREADS -D_REENTRANT -DOPERATOR_NEW_ARRAY -c -I. ./cord/cordbscs.c
mv cordbscs.o cord/cordbscs.o
cc  -O -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DALL_INTERIOR_POINTERS -DSILENT -DLINUX_THREADS -D_REENTRANT -DOPERATOR_NEW_ARRAY -c -I. ./cord/cordxtra.c
mv cordxtra.o cord/cordxtra.o
cc  -O -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DALL_INTERIOR_POINTERS -DSILENT -DLINUX_THREADS -D_REENTRANT -DOPERATOR_NEW_ARRAY -c -I. ./cord/cordprnt.c
mv cordprnt.o cord/cordprnt.o
rm -f cord/cordtest
./if_mach SPARC DRSNX cc  -O -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DALL_INTERIOR_POINTERS -DSILENT -DLINUX_THREADS -D_REENTRANT -DOPERATOR_NEW_ARRAY -o cord/cordtest ./cord/cordtest.c cord/cordbscs.o cord/cordxtra.o cord/cordprnt.o gc.a -lucb
./if_mach HP_PA HPUX cc  -O -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DALL_INTERIOR_POINTERS -DSILENT -DLINUX_THREADS -D_REENTRANT -DOPERATOR_NEW_ARRAY -o cord/cordtest ./cord/cordtest.c cord/cordbscs.o cord/cordxtra.o cord/cordprnt.o gc.a -ldld `./threadlibs`
./if_not_there cord/cordtest cc  -O -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DALL_INTERIOR_POINTERS -DSILENT -DLINUX_THREADS -D_REENTRANT -DOPERATOR_NEW_ARRAY -o cord/cordtest ./cord/cordtest.c cord/cordbscs.o cord/cordxtra.o cord/cordprnt.o gc.a `./threadlibs`
^^^^Starting command^^^^
cord/cordtest
SUCCEEDED
---end included output---

I'm using Linux kernel 2.2.5-15 with glibc 2.1.3-15.

Ben

On Mon, Apr 17, 2000 at 10:26:08AM -0700, Boehm, Hans wrote:
> I haven't tried exactly that combination.  But I expect you should be using
> new_gc_alloc.h, which is intended for recent versions of the STL.  If that
> doesn't work, please let me know, and I'll track it down.  I'll change the
> documentation to make that a little less confusing.
> 
> -DREDIRECT_MALLOC is not recommended with the standard allocator.  The
> problem is that the default SGI allocator uses malloc to allocate large
> chunks of memory.  The garbage collector should reclaim those large chunks
> when they become completely inaccessible, but it cannot reclaim individual
> objects.  This may be enough to eventually bound heap growth, but since the
> chunk size grows in geometric progression, that's very unlikely to happen
> before you run out of memory and/or address space.
> 
> -DREDIRECT_MALLOC should work if you use the malloc_alloc STL allocator,
> since that calls malloc directly for each object.
> 
> I just made version 5.0alpha6 available.  I'd particularly appreciate bug
> reports aginst that version, since I would like to finally turn this into a
> real release.
> 
> Hans
> 
> -----Original Message-----
> From: Benjamin Geer [mailto:benjamin.geer@btinternet.com]
> Sent: Sunday, April 16, 2000 4:29 PM
> To: gclist@iecc.com
> Subject: [gclist] Boehm gc with STL from gcc 2.95.2?
> 
> 
> I'm resending this message because it doesn't seem to have gone
> through the first time.  My apologies if anyone gets it twice.
> 
> Has anyone got the Boehm-Demers-Weiser collector working with the
> version of the STL that's included in gcc 2.95.2?  I tried the
> gc_alloc.h supplied with gc, and got a lot of compiler errors in the
> STL header files.  I then tried compiling gc with
> -DREDIRECT_MALLOC=GC_malloc and -DIGNORE_FREE, since the default STL
> allocator seems to use malloc, but this had no effect as far as I
> could tell.  (I included gc_cpp.h, derived a class Foo from
> gc_cleanup, and put some pointers to Foos in an STL list; destructors
> weren't called on those objects when the list went out of scope, not
> even after calling GC_gcollect().)  I'm using gc5.0alpha4 on Linux
> i386.
> 
> Benjamin Geer
> benjamin.geer@btinternet.com