Makefile.am, [...]: Imported GC 6.0 and merged local changes.

	* Makefile.am, acinclude.m4, configure.in: Imported GC 6.0 and
	merged local changes.

From-SVN: r44994

6 files changed, 131 insertions, 69 deletions

diff --git a/boehm-gc/doc/README b/boehm-gc/doc/README
index cbd4323..c6b48c3 100644
--- a/boehm-gc/doc/README
+++ b/boehm-gc/doc/README
@@ -9,6 +9,9 @@ Copyright (c) 1998 by Fergus Henderson.  All rights reserved.
 The files Makefile.am, and configure.in are
 Copyright (c) 2001 by Red Hat Inc. All rights reserved.
 
+The files config.guess and a few others are copyrighted by the Free
+Software Foundation.
+
 THIS MATERIAL IS PROVIDED AS IS, WITH ABSOLUTELY NO WARRANTY EXPRESSED
 OR IMPLIED.  ANY USE IS AT YOUR OWN RISK.
 
@@ -18,7 +21,13 @@ Permission to modify the code and to distribute modified code is granted,
 provided the above notices are retained, and a notice that the code was
 modified is included with the above copyright notice.
 
-This is version 6.0alpha7 of a conservative garbage collector for C and C++.
+A few of the files needed to use the GNU-style build procedure come with
+slightly different licenses, though they are all similar in spirit.  A few
+are GPL'ed, but with an exception that should cover all uses in the
+collector.  (If you are concerned about such things, I recommend you look
+at the notice in config.guess or ltmain.sh.)
+
+This is version 6.0 of a conservative garbage collector for C and C++.
 
 You might find a more recent version of this at
 
diff --git a/boehm-gc/doc/README.MacOSX b/boehm-gc/doc/README.MacOSX
index 82343dd..2abf0b4 100644
--- a/boehm-gc/doc/README.MacOSX
+++ b/boehm-gc/doc/README.MacOSX
@@ -17,3 +17,11 @@ June, 1 2000
 
 Dietmar Planitzer
 dave.pl@ping.at
+
+Note from Andrew Begel:
+
+One more fix to enable gc.a to link successfully into a shared library for
+MacOS X. You have to add -fno-common to the CFLAGS in the Makefile. MacOSX
+disallows common symbols in anything that eventually finds its way into a
+shared library. (I don't completely understand why, but -fno-common seems to
+work and doesn't mess up the garbage collector's functionality).
diff --git a/boehm-gc/doc/README.changes b/boehm-gc/doc/README.changes
index b067688..c018c8b 100644
--- a/boehm-gc/doc/README.changes
+++ b/boehm-gc/doc/README.changes
@@ -1291,7 +1291,103 @@ Since 6.0alpha6:
    There seemed to be some problems with the encoding of root and finalizer
    references.
   
+Since 6.0alpha7:
+ - Changed GC_debug_malloc_replacement and GC_debug_realloc_replacement
+   so that they compile under Irix.  (Thanks to Dave Love.)
+ - Updated powerpc_macosx_mach_dep.s so that it works if the collector
+   is in a dynamic library.  (Thanks to Andrew Begel.)
+ - Transformed README.debugging into debugging.html, updating and
+   expanding it in the process.  Added gcdescr.html and tree.html
+   from the web site to the GC distribution.
+ - Fixed several problems related to PRINT_BLACK_LIST. This involved
+   restructuring some of the marker macros.
+ - Fixed some problems with the sizing of objects with debug information.
+   Finalization was broken KEEP_BACK_PTRS or PRINT_BLACK_LIST.  Reduced the
+   object size with SHORT_DEBUG_HDRS by another word.
+ - The "Needed to allocate blacklisted ..." warning had inadvertently
+   been turned off by default, due to a buggy test in allchblk.c.  Turned
+   it back on.
+ - Removed the marker macros to deal with 2 pointers in interleaved fashion.
+   They were messy and the performance improvement seemed minimal.  We'll
+   leave such scheduling issues to the compiler.
+ - Changed Linux/PowerPC test to also check for __powerpc__ in response
+   to a discussion on the gcc mailing list.
+ - On Matthew Flatt's suggestion removed the "static" from the jmp_buf
+   declaration in GC_generic_push_regs.  This was causing problems in
+   systems that register all of their own roots.  It looks far more correct
+   to me without the "static" anyway. 
+ - Fixed several problems with thread local allocation of pointerfree or
+   typed objects.  The collector was reclaiming thread-local free lists, since
+   it wasn't following the link fields.
+ - There was apparently a long-standing race condition related to multithreaded
+   incremental collection.  A collection could be started and a thread stopped
+   between the memory unprotect system call and the setting of the
+   corresponding dirt bit.  I believe this did not affect Solaris or PCR, which
+   use a different dirty-bit implementation.  Fixed this by installing
+   signal handlers with sigaction instead of signal, and disabling the thread
+   suspend signal while in the write-protect handler.  (It is unclear
+   whether this scenario ever actually occurred.  I found it while tracking
+   down the following:)
+ - Incremental collection did not cooperate correctly with the PARALLEL_MARK
+   implementation of GC_malloc_many or the local_malloc primitves.  It still
+   doesn't work well, but it shouldn't lose memory anymore.
+ - Integrated some changes from the gcc source tree that I had previously
+   missed.  (Thanks to Bryce McKinley for the reminder/diff.)
+ - Added Makefile.direct as a copy of the default Makefile, which would
+   normally be overwritten if configure is run.
+ - Changed the gc.tar target in Makefile.direct to embed the version number
+   in the gc directory name.  This will affect future tar file distributions.
+ - Changed the Irix dynamic library finding code to no longer try to
+   eliminate writable text segments under Irix6.x, since that is probably no
+   longer necessary, and can apparently be unsafe on occasion.  (Thanks to
+   Shiro Kawai for pointing this out.)
+ - GC_cleanup with GC_DEBUG enabled passed a real object base address to
+   GC_debug_register_finalizer_ignore_self, which expected a pointer past the
+   debug header.  Call GC_register_finalizer_ignore_self instead, even with
+   debugging enabled.  (Thanks to Jean-Daniel Fekete for catching this.)
+ - The collector didn't build with call chain saving enabled but NARGS=0.
+   (Thanks to Maarten Thibaut.)
+ - Fixed up the GNU-style build files enough so that they work in some
+   obvious cases.
+ - Added initial port to Digital Mars compiler for win32. (Thanks to Walter
+   Bright.)
+
+Since 6.0alpha8:
+ - added README.macros.
+ - Made gc.mak a symbolic link to work around winzip's tendency to ignore
+   hard links.
+ - Simplified the setting of NEED_FIND_LIMIT in os_dep.c, possibly breaking
+   it on untested platforms.
+ - Integrated initial GNU HURD port. (Thanks to Chris Lingard and Igor
+   Khavkine.)
+ - A few more fixes for Digital Mars compiler.
+ - Fixed gcc version recognition.  Renamed OPERATOR_NEW_ARRAY to
+   GC_OPERATOR_NEW_ARRAY.  Changed GC_OPERATOR_NEW_ARRAY to be the default.
+   It can be overridden with -DGC_NO_OPERATOR_NEW_ARRAY.  (Thanks to
+   Cesar Eduardo Barros.) 
+ - Changed the byte size to free-list mapping in thread local allocation
+   so that size 0 allocations are handled correctly.
+ - Fixed Linux/MIPS stackbottom for new toolchain. (Thanks to Ryan Murray.)
+ - Changed finalization registration to invoke GC_oom_fn when it runs out
+   of memory.
+ - Removed lvalue cast in finalize.c.  This caused some debug configurations
+   not to build with some non-gcc compilers.
+
+Since 6.0alpha9:
+ - Two more bug fixes for KEEP_BACK_PTRS and DBG_HDRS_ALL.
+ - Fixed a stack clearing problem that resulted in SIGILL with a
+   misaligned stack pointer for multithreaded SPARC builds.
+ - Integrated another HURD patch (thanks to Igor Khavkine).
+ 
+
 To do:
+ - There seem to be outstanding issues on Solaris/X86, possibly with
+   finding the data segment starting address.  Information/patches would
+   ne appreciated.
+ - New_gc_alloc.h is apparently no longer compatible with the latest C++
+   standard library in gcc3.0.  (This isn't technically a bug, since it only
+   claimed compatibility with the SGI STL.  But we may need a new C++ STL
+   allocator interface.)
  - Very large root set sizes (> 16 MB or so) could cause the collector
    to abort with an unexpected mark stack overflow.  (Thanks again to
    Peter Chubb.)  NOT YET FIXED.  Workaround is to increase the initial
diff --git a/boehm-gc/doc/README.cords b/boehm-gc/doc/README.cords
index 16ce008..3485e01 100644
--- a/boehm-gc/doc/README.cords
+++ b/boehm-gc/doc/README.cords
@@ -18,6 +18,20 @@ See cord.h for a description of the functions provided.  Ec.h describes
 to a cord.  These allow for efficient construction of cords without
 requiring a bound on the size of a cord.
 
+More details on the data structure can be found in
+
+Boehm, Atkinson, and Plass, "Ropes: An Alternative to Strings",
+Software Practice and Experience 25, 12, December 1995, pp. 1315-1330.
+
+A fundamentally similar "rope" data structure is also part of SGI's standard
+template library implementation, and its descendents, which include the
+GNU C++ library.  That uses reference counting by default.
+There is a short description of that data structure at
+http://reality.sgi.com/boehm/ropeimpl.html .  (The more official location
+http://www.sgi.com/tech/stl/ropeimpl.html is missing a figure.)
+
+All of these are descendents of the "ropes" in Xerox Cedar.
+
 de.c is a very dumb text editor that illustrates the use of cords.
 It maintains a list of file versions.  Each version is simply a
 cord representing the file contents.  Nonetheless, standard
diff --git a/boehm-gc/doc/README.debugging b/boehm-gc/doc/README.debugging
deleted file mode 100644
index f4dd656..0000000
--- a/boehm-gc/doc/README.debugging
+++ /dev/null
@@ -1,68 +0,0 @@
-Debugging suggestions:
-
-****If you get a segmentation fault or bus error while debugging with a debugger:
-If the fault occurred in GC_find_limit, or with incremental collection enabled, this is probably normal.  The collector installs handlers to take care of these.  You will not see these unless you are using a debugger.  Your debugger should allow you to continue.  It's preferable to tell the debugger to ignore SIGBUS and SIGSEGV ("handle" in gdb, "ignore" in most versions of dbx) and set a breakpoint in abort.  The collector will call abort if the signal had another cause, and there was not other handler previously installed.  I recommend debugging without incremental collection if possible.  (This applies directly to UNIX systems.  Debugging with incremental collection under win32 is worse.  See README.win32.)  
-
-****If you get warning messages informing you that the collector needed to allocate blacklisted blocks:
-
-0) Ignore these warnings while you are using GC_DEBUG.  Some of the routines mentioned below don't have debugging equivalents.  (Alternatively, write the missing routines and send them to me.)
-
-1) Replace allocator calls that request large blocks with calls to GC_malloc_ignore_off_page or GC_malloc_atomic_ignore_off_page.  You may want to set a breakpoint in GC_default_warn_proc to help you identify such calls.  Make sure that a pointer to somewhere near the beginning of the resulting block is maintained in a (preferably volatile) variable as long as the block is needed.
-
-2) If the large blocks are allocated with realloc, I suggest instead allocating them with something like the following.  Note that the realloc size increment should be fairly large (e.g. a factor of 3/2) for this to exhibit reasonable performance.  But we all know we should do that anyway.
-
-void * big_realloc(void *p, size_t new_size)
-{
-    size_t old_size = GC_size(p);
-    void * result;
- 
-    if (new_size <= 10000) return(GC_realloc(p, new_size));
-    if (new_size <= old_size) return(p);
-    result = GC_malloc_ignore_off_page(new_size);
-    if (result == 0) return(0);
-    memcpy(result,p,old_size);
-    GC_free(p);
-    return(result);
-}
-
-3) In the unlikely case that even relatively small object (<20KB) allocations are triggering these warnings, then your address space contains lots of "bogus pointers", i.e. values that appear to be pointers but aren't.  Usually this can be solved by using GC_malloc_atomic or the routines in gc_typed.h to allocate large pointerfree regions of bitmaps, etc.  Sometimes the problem can be solved with trivial changes of encoding in certain values.  It is possible, though not pleasant, to identify the source of the bogus pointers by setting a breakpoint in GC_add_to_black_list_stack, and looking at the value of current_p in the GC_mark_from_mark_stack frame.  Current_p contains the address of the bogus pointer.
-
-4) If you get only a fixed number of these warnings, you are probably only introducing a bounded leak by ignoring them.  If the data structures being allocated are intended to be permanent, then it is also safe to ignore them.  The warnings can be turned off by calling GC_set_warn_proc with a procedure that ignores these warnings (e.g. by doing absolutely nothing).
-
-
-****If the collector dies in GC_malloc while trying to remove a free list element:
-
-1) With > 99% probability, you wrote past the end of an allocated object.  Try setting GC_DEBUG and using the debugging facilities in gc.h.
-
-
-****If the heap grows too much:
-
-1) Consider using GC_malloc_atomic for objects containing nonpointers.  This is especially important for large arrays containg compressed data, pseudo-random numbers, and the like.  (This isn't all that likely to solve your problem, but it's a useful and easy optimization anyway, and this is a good time to try it.)   If you allocate large objects containg only one or two pointers at the beginning, either try the typed allocation primitives is gc.h, or separate out the pointerfree component.
-2) If you are using the collector in its default mode, with interior pointer recognition enabled, consider using GC_malloc_ignore_off_page to allocate large objects.  (See gc.h and above for details.  Large means > 100K in most environments.)
-3) GC_print_block_list() will print a list of all currently allocated heap blocks and what size objects they contain.  GC_print_hblkfreelist() will print a list of free heap blocks, and whether they are blacklisted.  GC_dump calls both of these, and also prints information about heap sections, and root segments.
-4) Build the collector with -DKEEP_BACK_PTRS, and use the backptr.h
-interface to determine why objects are being retained.
-
-
-****If the collector appears to be losing objects:
-
-1) Replace all calls to GC_malloc_atomic and typed allocation by GC_malloc calls.  If this fixes the problem, gradually reinsert your optimizations.
-2) You may also want to try the safe(r) pointer manipulation primitives in gc.h.  But those are hard to use until the preprocessor becomes available.
-3) Try using the GC_DEBUG facilities.  This is less likely to be successful here than if the collector crashes.
-[The rest of these are primarily for wizards.  You shouldn't need them unless you're doing something really strange, or debugging a collector port.]
-4) Don't turn on incremental collection.  If that fixes the problem, suspect a bug in the dirty bit implementation.  Try compiling with -DCHECKSUMS to check for modified, but supposedly clean, pages.
-5) On a SPARC, in a single-threaded environment, GC_print_callers(GC_arrays._last_stack) prints a cryptic stack trace as of the time of the last collection.  (You will need a debugger to decipher the result.)  The question to ask then is "why should this object have been accessible at the time of the last collection?  Where was a pointer to it stored?".  This facility should be easy to add for some other collector ports (namely if it's easy to traverse stack frames), but will be hard for others.
-6) "print *GC_find_header(p)" in dbx or gdb will print the garbage collector block header information associated with the object p (e.g. object size, etc.)
-7) GC_is_marked(p) determines whether p is the base address of a marked object.  Note that objects allocated since the last collection should not be marked, and that unmarked objects are reclaimed incrementally.  It's usually most interesting to set a breakpoint in GC_finish_collection and then to determine how much of the damaged data structure is marked at that point.
-8) Look at the tracing facility in mark.c.  (Ignore this suggestion unless you are very familiar with collector internals.)
-9) [From Melissa O'Neill:]
-If you're using multiple threads, double check that all thread
-creation goes through the GC_ wrapper functions rather than
-calling the thread-creation functions themselves (e.g.,
-GC_pthread_create rather than pthread_create).  The gc.h header
-file includes suitable preprocessor definitions to accomplish
-this mapping transparently -- the question is: are you including
-it in all the modules that create threads?
-
-
-
diff --git a/boehm-gc/doc/README.environment b/boehm-gc/doc/README.environment
index 4681acf..5760342 100644
--- a/boehm-gc/doc/README.environment
+++ b/boehm-gc/doc/README.environment
@@ -29,6 +29,9 @@ GC_NPROCS=<n> - Linux w/threads only.  Explicitly sets the number of processors
 		when multiple processors are available will preserve
 		correctness, but may lead to really horrible performance.
 
+GC_NO_BLACKLIST_WARNING - Prevents the collector from issuing
+		"Needed to allocate blacklisted block at ..." warnings.
+
 The following turn on runtime flags that are also program settable.  Checked
 only during initialization.  We expect that they will usually be set through
 other means, but this may help with debugging and testing: