configure.in (GCINCS): Don't use "boehm-cflags".

libjava:
2004-08-13  Bryce McKinlay  <mckinlay@redhat.com>

	* configure.in (GCINCS): Don't use "boehm-cflags". Instead, -I
	boehm-gc's include dirs.
	* configure: Rebuilt.
	* include/boehm-gc.h: Include gc_config.h.

boehm-gc:
2004-08-13  Bryce McKinlay  <mckinlay@redhat.com>

	* configure.ac (gc_cflags): Add -Iinclude.
	(AC_CONFIG_HEADERS): New. Configure gc_config.h header.
	Don't write DEFS to boehm-cflags file.
	* configure: Rebuilt.
	* gcj_mlc.c: Check #ifdef GC_GCJ_SUPPORT after including headers.
	* specific.c: Check #ifdef GC_LINUX_THREADS after including headers.
	* include/gc_config_macros.h: Remove backward-compatibility
	redefinitions of GC_ names.
	* include/gc.h: Include <gc_config.h>.

2004-08-13  Bryce McKinlay  <mckinlay@redhat.com>

	Import Boehm GC version 6.3.

From-SVN: r85972

8 files changed, 415 insertions, 55 deletions

diff --git a/boehm-gc/doc/README b/boehm-gc/doc/README
index 29d954f..ff77113 100644
--- a/boehm-gc/doc/README
+++ b/boehm-gc/doc/README
@@ -1,7 +1,7 @@
 Copyright (c) 1988, 1989 Hans-J. Boehm, Alan J. Demers
 Copyright (c) 1991-1996 by Xerox Corporation.  All rights reserved.
 Copyright (c) 1996-1999 by Silicon Graphics.  All rights reserved.
-Copyright (c) 1999-2003 by Hewlett-Packard Company. All rights reserved.
+Copyright (c) 1999-2004 Hewlett-Packard Development Company, L.P.
 
 The file linux_threads.c is also
 Copyright (c) 1998 by Fergus Henderson.  All rights reserved.
@@ -28,7 +28,7 @@ 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.3alpha1 of a conservative garbage collector for C and C++.
+This is version 6.3 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.changes b/boehm-gc/doc/README.changes
index 619ea2e4..e27e7d6 100644
--- a/boehm-gc/doc/README.changes
+++ b/boehm-gc/doc/README.changes
@@ -1836,7 +1836,7 @@ Since 6.2alpha4:
    libgccpp.
 
 Since 6.2alpha5:
- - There was extra underscore in the name of GC_save_registers_in_stack
+ - There was an extra underscore in the name of GC_save_registers_in_stack
    for NetBSD/SPARC.  (Thanks to Jaap Boender for the patch.)
  - Integrated Brian Alliet's patch for Darwin.  This restructured the
    linuxthreads/pthreads support to separate generic pthreads support
@@ -1894,7 +1894,219 @@ Since 6.2:
    (Thanks to Roger Sayle for the patch.)
  - Applied more AIX threads patches from Scott Ananian.
 
+Since 6.3alpha1:
+ - Reenabled I_HOLD_LOCK assertion in aix_irix_threads.h.
+ - Put back the WINABI qualifier for GC_CreateThread.  (Thanks to
+   Danny Smith for the patch.  6.3alpha1 had the qualifier in one place
+   but not elsewhere, which was clearly wrong.)
+ - Sometimes explicitly define __private_extern__ before DARWIN dyld.h
+   include.  (Thanks to Andreas Tobker for postting the patch.)
+ - Included signal.h from pthread_support.c.  Removed GC_looping_handler,
+   which was dead code.
+ - GC_find_start was misdeclared by gc_pmark.h if PRINT_BLACK_LIST was
+   defined.  (Thanks to Glauco Masotti for testing and reporting this.)
+   Changed GC_find_start to never just return 0.  According to its
+   comment it doesn't, and it's unclear that's correct.
+ - GC_alloc_large had several largely compensating bugs in the
+   computation of GC_words_wasted.  (It was confused about bytes vs.
+   words in two places.)
+ - Integrated Slava Sysoltev's patch to support more recent versions of
+   the Intel compiler on IA64/Linux.
+ - Changed win32 spinlock initialization to conditionally set a spin count.
+   (Emmanual Stumpf pointed out that enabling this makes a large performance
+   difference on win32 multiprocessors.)  Also cleaned up the win32 spinlock
+   initialization code a bit.
+ - Fixed thread support for HP/UX/IA64.  The register backing store base for
+   the main thread was sometimes not set correctly.  (Thanks to Laurent
+   Morichetti.)
+ - Added -DEMPTY_GETENV_RESULTS flag to work around Wine problem.
+ - Declare GC_stack_alloc and GC_stack_free in solaris_threads.h to
+   avoid 64-bit size mismatches.  (Thanks to Bernie Solomon.)
+ - Fixed GC_generic_push_regs to avoid a potential and very unfortunate
+   tail call optimization.  This could lead to prematurely reclaimed
+   objects on configurations that used the generic routine and the new
+   build infrastructure (which potentially optimizes mach_dep.c).
+   This was a serious bug, but it's unclear whether it has resulted in
+   any real failures.
+ - Fixed CORD_str to deal with signed characters.  (Thanks to Alexandr
+   Petrosian for noticing the problem and supplying the patch.)
+ - Merged a couple of NOSYS/ECOS tests into os_dep.c from gcj.  (Thanks
+   to Anthony Green.)
+ - Partially merged a win32 patch from Ben Hutchings, and substantially
+   revised other parts of win32_threads.c.  It had several problems.
+   Under MinGW with a statically linked library, the main thread was
+   not registered.  Cygwin detached threads leaked thread descriptors.
+   There were several race conditions.  For now, unfortunately the
+   static threads limit remains, though we increased it, and made table
+   traversal cost depend on the actual thread count.
+   There is also still some code duplication with pthread_support.c.
+   (Thread descriptors did become much smaller, since Ben Hutchings
+   removed the thread context from them.)
+ - Integrated a Solaris configure.in patch from Rainer Orth.
+ - Added GC_IGNORE_FB and associated warning to very partially address
+   the issue of the collector treating a mapped frame buffer as part
+   of the root set.  (Thanks to David Peroutka for providing some
+   insight.  More would be helpful.  Is there anything that can be used
+   to at least partially identify such memory segments?)
+   
+Since 6.3alpha2:
+ - Removed -DSMALL_CONFIG from BCC_MAKEFILE.
+ - Changed macros to test for an ARM processor (Patch from Richard Earnshaw.)
+ - Mostly applied a DJGPP patch from Doug Kaufman.  Especially Makefile.dj
+   had suffered from serious bit rot.
+ - Rewrote GC_apply_to_maps, eliminating an off-by-one subscript error,
+   and a call to alloca (for lcc compatibility).
+ - Changed USE_MUNMAP behavior on posixy platforms to immediately remap
+   the memory with PROT_NONE instead of unmapping it.  The latter risks
+   an intervening mmap grabbing the address space out from underneath us.
+   Updated this code to reflect a cleaner patch from Ulrich Drepper.
+ - Replaced _T with _Tp in new_gc_alloc.h to avoid a MACOS X conflict.
+   (Patch from Andrew Begel.)
+ - Dynamically choose whether or not lock should spin on win32.  (Thanks
+   to Maurizio Vairani for the patch.)  This may be a significant performance
+   improvement for win32.
+ - Fix Makefile.direct to actually include NT_STATIC_THREADS_MAKEFILE
+   in the distribution.  (Again thanks to Maurizio Vairani.)
+ - Maybe_install_looping_handler() was accidentally exported, violating
+   our name space convention.
+ - Made os_dep.c use sigsetjmp and SA_NODEFER for NetBSD.  (Thanks to
+   Christian Limpach.)  (I generalized the patch to use sigsetjmp on all
+   UNIX_LIKE platforms, admittedly a slightly risky move.  But it may avoid
+   similar problems on some other platforms. I also cleaned up the defn
+   of UNIX_LIKE a bit. - Hans)
+ - Integrated Andrew Begel's Darwin threads patch, adjusted according to
+   some of Fergus Hendersons's comments.  (Patch didn't apply cleanly,
+   errors are possible.)
+ - Added another test or two for the Intel 8.0 compiler to avoid
+   confusing it with gcc.  The single-threaded collector should now build
+   with icc, at least on ia64. 
+
+Since 6.3alpha3:
+ - USE_MMAP was broken by confusion in the code dealing with USE_MMAP_ANON.
+   (This was pointed out, and fixes were suggested by several other people.)
+ - Darwin supprt was broken in alpha3 as a result of my misintegration of
+   Andrew Begel's patches.  Fixed with another patch from Andrew Begel.
+ - A new sanity check in pthread_stop_world.c:GC_push_all_stacks() was
+   overly aggressive.  We may collect from an unregistered thread during
+   thread creation.  Fixed by explicitly checking for that case.  (Added
+   GC_in_thread_creation.)
+
+Since 6.3alpha4:
+ - Fix & vs && typo in GC_generic_malloc and
+   GC_generic_malloc_ignore_off_page.  (Propagated from the gcc tree.)
+ - Removed SA_NODEFER hack from NetBSD and Solaris write-protect handler.
+   (According to Christian Limpach, the NetBSD problem is fixed.
+   Presumably so is the Solaris 2.3 problem.)
+ - Removed placement delete from gc_cpp.h for the SGI compiler.
+   (Thanks to Simon Gornall for the patch.)
+ - Changed semantics of the GC_IGNORE_FB environment variable, based 
+   on experimentation by Nicolas Cannasse pointing out that the old
+   interpretation was useless.  We still need help in identifying win32
+   graphics memory mappings.  The current "solution" is a hack.
+ - Removed "MAKEOVERRIDES =" from Makefile.am and thus Makefile.in.
+   It probably made more sense in the gcc context.
+ - Explicitly ensure that NEED_FIND_LIMIT is defined for {Open,Net}BSD/ELF.
+ - Replaced USE_HPUX_TLS macro by USE_COMPILER_TLS, since gcc often
+   supports the same extension on various platforms.
+ - Added some basic (completely untested) defines for win64, in support
+   of future work.
+ - Declared GC_jmp_buf in os_dep.s as JMP_BUF instead of jmp_buf, fixing
+   a memory overwrite bug on Solaris and perhaps other platforms.
+ - Added 0 != __libc_stack_end test to GC_linux_stack_base.  (Thanks to Jakub
+   Jelinek, both for the patch, and for explaining the problem to me.)
+   Otherwise "prelink"ing could cause the collector to fail.
+ - Changed default thread local storage implementation to USE_PTHREAD_SPECIFIC
+   for HP/UX with gcc.  The compiler-based implementation appears to work
+   only with the vendor compiler.
+ - Export GC_debug_header_size and GC_USR_PTR_FROM_BASE from gc_mark.h,
+   making client mark code cleaner and less dependent on GC version.
+ - Export several new procedures and GC_generic_malloc from gc_mark.h
+   to support user-defined kinds.  Use the new procedures to replace existing
+   code in gcj_mlc.c and typd_mlc.c.
+ - Added support for GC_BACKTRACES.
+ - Fixed a remaining problem in CORD_str with signed characters.  (Thanks
+   to Alexandr Petrosian for the patch.)
+ - Removed supposedly redundant, but very buggy, definitions of finalizer
+   macros from javaxfc.h.  Fortunately this file probably has no users.
+   The correct declarations were already in gc.h.
+ - Also need to set GC_in_thread_creation while waiting for GC during
+   thread termination, since it is also possible to collect from an
+   unregistered thread in that case.
+ - Define NO_GETENV for Windows CE, since getenv doesn't appear to exist.
+   + some other minor WinCE fixes. (Thanks to Alain Novak.)
+ - Added GC_register_describe_type_fn.
+ - Arrange for debugging finalizer registration to ignore non-heap
+   registrations, since the regular version of the routine also behaves
+   that way.
+ - GC_gcj_malloc and friends need to check for finalizers waiting to be run.
+   One of the more obscure allocation routines with missing a LOCK() call.
+ - Fixed cvtres invocations in NT_MAKEFILE and NT_STATIC_THREADS_MAKEFILE
+   to work with VS.NET.
+ - Cleaned up GC_INIT calls in test.  Updated gc.man to encourage GC_INIT
+   use in portable code.
+ - Taught the GC to use libunwind if --enable-full-debug is specified on
+   IA64 and libunwind is present.
+ - The USE_MUNMAP code could get confused about the age of a block and
+   prematurely unmap it.  GC_unmap_old had a bug related to wrapping of
+   GC_gc_no.  GC_freehblk and GC_merge_unmapped didn't maintain
+   hb_last_reclaimed reasonably when blocks were merged.  The code was
+   fixed to reflect original intent, but that may not always be an
+   improvement.  See todo list item.
+
+Since 6.3alpha5:
+ - Define USE_GENERIC_PUSH_REGS for NetBSD/M68K.
+ - Fixed the X86_64 PREFETCH macros to correctly handle ia32e (which uses
+   different prefetch instructions from AMD64).  (Thanks to H.J. Lu.)
+ - GC_config_macros.h did not correctly define GC_WIN32_THREADS from
+   GC_THREADS. 
+ - Added simple_example.html.
+ - Merged Andrew Gray's patch to correctly restore signal handlers on
+   FreeBSD.
+ - Merged a patch from Andreas Jaeger to deal with prefetch-related warnings
+   on x86-64.  Added some other casts so that the PREFETCH macros
+   always get a ptr_t argument.  Removed some casts inthe PREFETCH
+   implementations.
+ - At Jesse Jones suggestion: Added a header guard for gc_allocator.h
+   and changed GC_debug_free to clobber contents of deallocated object.
+ - The signal masking code in pthread_stop_world.c contained some errors.
+   In particular SIGSEGV was masked in the handler, in spite of the fact that
+   it wrote to the heap.  This could lead to an uncaught SIGSEGV, which
+   apparently became much more likely in Linux 2.6.  Also fixed some
+   typos, and reduced code duplication in the same area.
+ - Remove ltconfig, clean up configure messages for DGUX (thanks to
+   Adrian Bunk for the patches).
+ - Integrated NetBSD/OpenBSD patches from Marc Recht and Matthias Drochner.
+
+Since gc6.3alpha6:
+ - Compile test_cpp.cc with CXXCOMPILE instead of COMPILE.
+ - Very large allocations could cause a collector hang.  Correct
+   calculation of GC_collect_at_heapsize.
+ - GC_print_hblkfreelist printed some bogus results if USE_MUNMAP
+   was defined.
+ - The generic GC_THREADS macro didn't work correctly on Solaris,
+   since the implementation failed to include gc_config_macros.h
+   before deciding whether or not to compile the rest of the file.
+ - Threadlibs.c failed to expand the generic GC_THREADS macro.
+ - Correct MacOSX thread stop code. (Thanks to Dick Porter.)
+ - SMALL_OBJ definition was off by one.  This could cause crashes
+   at startup.  (Thanks to Zoltan Varga for narrowing this down to
+   a trivial test case.)
+ - Integrate Paolo Molara's patch to deal with a race in the Darwin
+   thread stopping code.
+ - Changed X86_64 implementation to use SA_SIGINFO in the MPROTECT_VDB
+   implementation.  The old approach appears to have been broken by
+   recent kernels.
+ - Add GC_ATTR_UNUSED to eliminate a warning in gc_allocator.h.  (Thanks
+   to Andrew Begel.)
+ - Fix GC_task_self declaration in os_dep.c.  (Thanks to Andrew Pinski.)
+ - Increase INITIAL_BUF_SZ in os_dep.c for Solaris /proc reads.
+  
 To do:
+ - The USE_MUNMAP code should really use a separate data structure
+   indexed by physical page to keep track of time since last use of
+   a page.  Using hblk headers means we lose track of ages when
+   blocks are merged, and we can't unmap pages that have been allocated and
+   dropped by the blacklisting code.  I suspect both of these matter.
  - A dynamic libgc.so references dlopen unconditionally, but doesn't link
    against libdl.
  - GC_proc_fd for Solaris is not correctly updated in response to a
diff --git a/boehm-gc/doc/README.environment b/boehm-gc/doc/README.environment
index d1f3b5c..97a13dc 100644
--- a/boehm-gc/doc/README.environment
+++ b/boehm-gc/doc/README.environment
@@ -1,6 +1,6 @@
 The garbage collector looks at a number of environment variables which are
 then used to affect its operation.  These are examined only on Un*x-like
-platforms.
+platforms and win32.
 
 GC_INITIAL_HEAP_SIZE=<bytes> -	Initial heap size in bytes.  May speed up
 				process start-up.
@@ -26,6 +26,14 @@ GC_DUMP_REGULARLY - Generate a GC debugging dump GC_dump() on startup
 		    if you have a bug to report, but please include only the
 		    last complete dump.
 
+GC_BACKTRACES=<n> - Generate n random backtraces (for heap profiling) after
+		    each GC.  Collector must have been built with
+		    KEEP_BACK_PTRS.  This won't generate useful output unless
+		    most objects in the heap were allocated through debug
+		    allocators.  This is intended to be only a statistical
+		    sample;  individual traces may be erroneous due to
+		    concurrent heap mutation.
+
 GC_PRINT_ADDRESS_MAP - Linux only.  Dump /proc/self/maps, i.e. various address
 		       maps for the process, to stderr on every GC.  Useful for
 		       mapping root addresses to source for deciphering leak
@@ -86,6 +94,28 @@ GC_RETRY_SIGNALS, GC_NO_RETRY_SIGNALS - Try to compensate for lost
 		     was turned into a runtime flag to enable last-minute
 		     work-arounds.
 
+GC_IGNORE_FB[=<n>] -  (Win32 only.) Try to avoid treating a mapped
+		frame buffer as part of the root set.  Certain (higher end?)
+		graphics cards seems to result in the graphics memory mapped
+		into the user address space as writable memory.
+		Unfortunately, there seems to be no systematic way to
+		identify such memory.  Setting the environment variable to n
+		causes the collector to ignore mappings longer than n MB.
+		The default value of n is currently 15.  (This should cover
+		a 16 MB graphics card, since the mapping appears to be slightly
+		shorter than all of graphics memory.  It will fail if a dll
+		writes pointers to collectable objects into a data segment
+		whose length is >= 15MB.  Empirically that's rare, but
+		certainly possible.)  WARNING: Security sensitive applications
+		should probably disable this feature by setting
+		GC_disallow_ignore_fb, or by building with -DNO_GETENV,
+		since small values could force collection of reachable
+		objects, which is conceivably a	(difficult to exploit)
+		security hole.  GC_IGNORE_FB values less than 3 MB
+		are never honored, eliminating this risk for most,
+		but not all, applications.  This feature is likely to disappear
+		if/when we find a less disgusting "solution".
+
 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:
diff --git a/boehm-gc/doc/README.macros b/boehm-gc/doc/README.macros
index b5fe679..df0ef2c 100644
--- a/boehm-gc/doc/README.macros
+++ b/boehm-gc/doc/README.macros
@@ -85,5 +85,10 @@ SRC_M3		Set if the collector is being built as a replacement of the
 		It's there primarily incase someone wants to port to a similar
 		system.
 
+USE_COMPILER_TLS  Assume the existence of __thread-style thread-local
+		storage.  Set automatically for thread-local allocation with
+		the HP/UX vendor compiler.  Usable with gcc on sufficiently
+		up-to-date ELF platforms.
+
 
 
diff --git a/boehm-gc/doc/README.win32 b/boehm-gc/doc/README.win32
index a40b375..6f57db1 100644
--- a/boehm-gc/doc/README.win32
+++ b/boehm-gc/doc/README.win32
@@ -1,34 +1,11 @@
-The collector has at various times been compiled under Windows 95 & NT,
-with the original Microsoft SDK, with Visual C++ 2.0, 4.0, and 6, with
-the GNU win32 environment, with Borland 4.5,  with Watcom C, and recently
+The collector has at various times been compiled under Windows 95 & later, NT,
+and XP, with the original Microsoft SDK, with Visual C++ 2.0, 4.0, and 6, with
+the GNU win32 tools, with Borland 4.5,  with Watcom C, and recently
 with the Digital Mars compiler.  It is likely that some of these have been
 broken in the meantime.  Patches are appreciated.
 
-It runs under both win32s and win32, but with different semantics.
-Under win32, all writable pages outside of the heaps and stack are
-scanned for roots.  Thus the collector sees pointers in DLL data
-segments.  Under win32s, only the main data segment is scanned.
-(The main data segment should always be scanned.  Under some
-versions of win32s, other regions may also be scanned.)
-Thus all accessible objects should be accessible from local variables
-or variables in the main data segment.  Alternatively, other data
-segments (e.g. in DLLs) may be registered with the collector by
-calling GC_init() and then GC_register_root_section(a), where
-a is the address of some variable inside the data segment.  (Duplicate
-registrations are ignored, but not terribly quickly.)
-
-(There are two reasons for this.  We didn't want to see many 16:16
-pointers.  And the VirtualQuery call has different semantics under
-the two systems, and under different versions of win32s.)
-
-Win32 applications compiled with some flavor of gcc currently behave
-like win32s applications, in that dynamic library data segments are
-not scanned.  (Gcc does not directly support Microsoft's "structured
-exception handling".  It turns out that use of this feature is
-unavoidable if you scan arbitrary memory segments obtained from
-VirtualQuery.)
-
-The collector test program "gctest" is linked as a GUI application,
+For historical reasons,
+the collector test program "gctest" is linked as a GUI application,
 but does not open any windows.  Its output appears in the file
 "gc.log".  It may be started from the file manager.  The hour glass
 cursor may appear as long as it's running.  If it is started from the
@@ -60,11 +37,23 @@ This is currently incompatible with -DUSE_MUNMAP.  (Thanks to Jonathan
 Clark for tracking this down.  There's some chance this may be fixed
 in 6.1alpha4, since we now separate heap sections with an unused page.)
 
+Microsoft Tools
+---------------
 For Microsoft development tools, rename NT_MAKEFILE as
 MAKEFILE.  (Make sure that the CPU environment variable is defined
 to be i386.)  In order to use the gc_cpp.h C++ interface, all
 client code should include gc_cpp.h.
 
+For historical reasons,
+the collector test program "gctest" is linked as a GUI application,
+but does not open any windows.  Its output appears in the file
+"gc.log".  It may be started from the file manager.  The hour glass
+cursor may appear as long as it's running.  If it is started from the
+command line, it will usually run in the background.  Wait a few
+minutes (a few seconds on a modern machine) before you check the output.
+You should see either a failure indication or a "Collector appears to
+work" message.
+
 If you would prefer a VC++.NET project file, ask boehm@acm.org.  One has
 been contributed, but it seems to contain some absolute paths etc., so
 it can presumably only be a starting point, and is not in the standard
@@ -75,13 +64,22 @@ Clients may need to define GC_NOT_DLL before including gc.h, if the
 collector was built as a static library (as it normally is in the
 absence of thread support).
 
+GNU Tools
+---------
 For GNU-win32, use the regular makefile, possibly after uncommenting
 the line "include Makefile.DLLs".  The latter should be necessary only
-if you want to package the collector as a DLL.  The GNU-win32 port is
+if you want to package the collector as a DLL.
+[Is the following sentence obsolete? -HB] The GNU-win32 port is
 believed to work only for b18, not b19, probably due to linker changes
 in b19.  This is probably fixable with a different definition of
 DATASTART and DATAEND in gcconfig.h.
 
+The collector should also be buildable under Cygwin with either the
+old standard Makefile, or with the "configure;make" machinery.
+
+Borland Tools
+-------------
+[Rarely tested.]
 For Borland tools, use BCC_MAKEFILE.  Note that
 Borland's compiler defaults to 1 byte alignment in structures (-a1),
 whereas Visual C++ appears to default to 8 byte alignment (/Zp8).
@@ -97,6 +95,8 @@ version, change the line near the top.  By default, it does not
 require the assembler.  If you do have the assembler, I recommend
 removing the -DUSE_GENERIC.
 
+Incremental Collection
+----------------------
 There is some support for incremental collection.  This is
 currently pretty simple-minded.  Pages are protected.  Protection
 faults are caught by a handler installed at the bottom of the handler
@@ -112,7 +112,11 @@ is called.)
 
 Note that incremental collection is disabled with -DSMALL_CONFIG.
 
-James Clark has contributed the necessary code to support win32 threads.
+Threads
+-------
+
+James Clark has contributed the necessary code to support win32 threads
+with the collector in a DLL.
 Use NT_THREADS_MAKEFILE (a.k.a gc.mak) instead of NT_MAKEFILE
 to build this version.  Note that this requires some files whose names
 are more than 8 + 3 characters long.  Thus you should unpack the tar file
@@ -128,12 +132,31 @@ This version relies on the collector residing in a dll.
 
 This version currently supports incremental collection only if it is
 enabled before any additional threads are created.
-Version 4.13 attempts to fix some of the earlier problems, but there
-may be other issues.  If you need solid support for win32 threads, you
-might check with Geodesic Systems.  Their collector must be licensed,
-but they have invested far more time in win32-specific issues.
 
-Hans
+Since 6.3alpha2, threads are also better supported in static library builds
+with Microsoft tools (use NT_STATIC_THREADS_MAKEFILE) and with the GNU
+tools.  In all cases,the collector must be built with GC_WIN32_THREADS
+defined, even if the Cygwin pthreads interface is used.
+(NT_STATIC_THREADS_MAKEFILE does this implicitly.  Under Cygwin,
+./configure --enable-threads=posix defines GC_WIN32_THREADS.)  Threads must be
+created with GC_CreateThread.  This can be accomplished by
+including gc.h and then calling CreateThread, which is redefined
+by gc.h.
+
+For the statically linked versions, it is required that GC_init()
+be called before other GC calls, since there seems to be no implicit way
+to initialize the allocation lock.  The easiest way to ensure this in
+portable code is to call GC_INIT() from the main executable (not
+a dynamic library) before calling any other GC_ routines.
+
+We strongly advise against using the TerminateThread() win32 API call,
+especially with the garbage collector.  Any use is likely to provoke a
+crash in the GC, since it makes it impossible for the collector to
+correctly track threads.
+
+
+Watcom compiler
+---------------
 
 Ivan V. Demakov's README for the Watcom port:
 
@@ -167,4 +190,26 @@ important, otherwise resulting programs will not run.
 
 Ivan Demakov (email: ivan@tgrad.nsk.su)
 
+Win32S
+------
+
+[The following is probably obsolete.  The win32s support is still in the
+collector, but I doubt anyone cares, or has tested it recently.]
+
+The collector runs under both win32s and win32, but with different semantics.
+Under win32, all writable pages outside of the heaps and stack are
+scanned for roots.  Thus the collector sees pointers in DLL data
+segments.  Under win32s, only the main data segment is scanned.
+(The main data segment should always be scanned.  Under some
+versions of win32s, other regions may also be scanned.)
+Thus all accessible objects should be accessible from local variables
+or variables in the main data segment.  Alternatively, other data
+segments (e.g. in DLLs) may be registered with the collector by
+calling GC_init() and then GC_register_root_section(a), where
+a is the address of some variable inside the data segment.  (Duplicate
+registrations are ignored, but not terribly quickly.)
+
+(There are two reasons for this.  We didn't want to see many 16:16
+pointers.  And the VirtualQuery call has different semantics under
+the two systems, and under different versions of win32s.)
 
diff --git a/boehm-gc/doc/debugging.html b/boehm-gc/doc/debugging.html
index 22273fe..7c65f2b 100644
--- a/boehm-gc/doc/debugging.html
+++ b/boehm-gc/doc/debugging.html
@@ -47,6 +47,10 @@ The garbage collector generates warning messages of the form
 <PRE>
 Needed to allocate blacklisted block at 0x...
 </pre>
+or
+<PRE>
+Repeated allocation of very large block ...
+</pre>
 when it needs to allocate a block at a location that it knows to be
 referenced by a false pointer.  These false pointers can be either permanent
 (<I>e.g.</i> a static integer variable that never changes) or temporary.
@@ -123,7 +127,8 @@ is commonly caused by data structures that are no longer being used,
 but were not cleared, or by caches growing without bounds.
 <LI> Pointer misidentification.  The garbage collector is interpreting
 integers or other data as pointers and retaining the "referenced"
-objects.
+objects.  A common symptom is that GC_dump() shows much of the heap
+as black-listed.
 <LI> Heap fragmentation.  This should never result in unbounded growth,
 but it may account for larger heaps.  This is most commonly caused
 by allocation of large objects.  On some platforms it can be reduced
@@ -180,6 +185,12 @@ primitives is <TT>gc_typed.h</tt>, or separate out the pointerfree component.
 <LI> Consider using <TT>GC_malloc_ignore_off_page()</tt>
 to allocate large objects.  (See <TT>gc.h</tt> and above for details.
 Large means &gt; 100K in most environments.)
+<LI> If your heap size is larger than 100MB or so, build the collector with
+-DLARGE_CONFIG.  This allows the collector to keep more precise black-list
+information.
+<LI> If you are using heaps close to, or larger than, a gigabyte on a 32-bit
+machine, you may want to consider moving to a platform with 64-bit pointers.
+This is very likely to resolve any false pointer issues.
 </ol>
 <H2>Prematurely Reclaimed Objects</h2>
 The usual symptom of this is a segmentation fault, or an obviously overwritten
diff --git a/boehm-gc/doc/gc.man b/boehm-gc/doc/gc.man
index 5409e70..2a550c7 100644
--- a/boehm-gc/doc/gc.man
+++ b/boehm-gc/doc/gc.man
@@ -1,12 +1,14 @@
-.TH GC_MALLOC 1L "12 February 1996"
+.TH GC_MALLOC 1L "2 October 2003"
 .SH NAME
 GC_malloc, GC_malloc_atomic, GC_free, GC_realloc, GC_enable_incremental, GC_register_finalizer, GC_malloc_ignore_off_page, GC_malloc_atomic_ignore_off_page, GC_set_warn_proc \- Garbage collecting malloc replacement
 .SH SYNOPSIS
 #include "gc.h"
 .br
-# define malloc(n) GC_malloc(n)
+void * GC_malloc(size_t size);
 .br
-... malloc(...) ...
+void GC_free(void *ptr);
+.br
+void * GC_realloc(void *ptr, size_t size);
 .br
 .sp
 cc ... gc.a
@@ -23,6 +25,11 @@ will attempt to reclaim inaccessible space automatically by invoking a conservat
 GC_malloc
 or friends.
 .LP
+In most cases it is preferable to call the macros GC_MALLOC, GC_FREE, etc.
+instead of calling GC_malloc and friends directly.  This allows debugging
+versions of the routines to be substituted by defining GC_DEBUG before
+including gc.h.
+.LP
 See the documentation in the include file gc_cpp.h for an alternate, C++ specific interface to the garbage collector.
 .LP
 Unlike the standard implementations of malloc,
@@ -56,9 +63,16 @@ It is also possible to use the collector to find storage leaks in programs desti
 .LP
 The collector may, on rare occasion produce warning messages.  On UNIX machines these appear on stderr.  Warning messages can be filtered, redirected, or ignored with
 .I
-GC_set_warn_proc.
+GC_set_warn_proc
 This is recommended for production code.  See gc.h for details.
 .LP
+Fully portable code should call
+.I
+GC_INIT
+from the main program before making any other GC calls.
+On most platforms this does nothing and the collector is initialized on first use.
+On a few platforms explicit initialization is necessary.  And it can never hurt. 
+.LP
 Debugging versions of many of the above routines are provided as macros.  Their names are identical to the above, but consist of all capital letters.  If GC_DEBUG is defined before gc.h is included, these routines do additional checking, and allow the leak detecting version of the collector to produce slightly more useful output.  Without GC_DEBUG defined, they behave exactly like the lower-case versions.
 .LP
 On some machines, collection will be performed incrementally after a call to
@@ -71,10 +85,13 @@ Other facilities not discussed here include limited facilities to support increm
 .SH "SEE ALSO"
 The README and gc.h files in the distribution.  More detailed definitions of the functions exported by the collector are given there.  (The above list is not complete.)
 .LP
+The web site at http://www.hpl.hp.com/personal/Hans_Boehm/gc .
+.LP
 Boehm, H., and M. Weiser, "Garbage Collection in an Uncooperative Environment",
 \fISoftware Practice & Experience\fP, September 1988, pp. 807-820.
 .LP
 The malloc(3) man page.
 .LP
 .SH AUTHOR
-Hans-J. Boehm (boehm@parc.xerox.com).  Some of the code was written by others, most notably Alan Demers.
+Hans-J. Boehm (Hans.Boehm@hp.com).
+Some of the code was written by others, most notably Alan Demers.
diff --git a/boehm-gc/doc/gcdescr.html b/boehm-gc/doc/gcdescr.html
index 8ecbac8..cab6bde 100644
--- a/boehm-gc/doc/gcdescr.html
+++ b/boehm-gc/doc/gcdescr.html
@@ -4,7 +4,7 @@
     <AUTHOR> Hans-J. Boehm, HP Labs (Much of this was written at SGI)</author>
 </HEAD>
 <BODY>
-<H1> <I>This is under construction</i> </h1>
+<H1> <I>This is under construction, and may always be.</i> </h1>
 <H1> Conservative GC Algorithmic Overview </h1>
 <P>
 This is a description of the algorithms and data structures used in our
@@ -27,20 +27,22 @@ We assume the default finalization model, but the code affected by that
 is very localized.
 <H2> Introduction </h2>
 The garbage collector uses a modified mark-sweep algorithm.  Conceptually
-it operates roughly in four phases:
+it operates roughly in four phases, which are performed occasionally
+as part of a memory allocation:
 
 <OL>
 
 <LI>
-<I>Preparation</i> Clear all mark bits, indicating that all objects
+<I>Preparation</i> Each object has an associated mark bit.
+Clear all mark bits, indicating that all objects
 are potentially unreachable.
 
 <LI>
 <I>Mark phase</i> Marks all objects that can be reachable via chains of
-pointers from variables.  Normally the collector has no real information
+pointers from variables.  Often the collector has no real information
 about the location of pointer variables in the heap, so it
 views all static data areas, stacks and registers as potentially containing
-containing pointers.  Any bit patterns that represent addresses inside
+pointers.  Any bit patterns that represent addresses inside
 heap objects managed by the collector are viewed as pointers.
 Unless the client program has made heap object layout information
 available to the collector, any heap objects found to be reachable from
@@ -87,8 +89,12 @@ others are not.  Some may have per-object type descriptors that
 determine pointer locations.  Or a specific kind may correspond
 to one specific object layout.  Two built-in kinds are uncollectable.
 One (<TT>STUBBORN</tt>) is immutable without special precautions.
-In spite of that, it is very likely that most applications currently
+In spite of that, it is very likely that most C clients of the
+collector currently
 use at most two kinds: <TT>NORMAL</tt> and <TT>PTRFREE</tt> objects.
+The <A HREF="http://gcc.gnu.org/java">gcj</a> runtime also makes
+heavy use of a kind (allocated with GC_gcj_malloc) that stores
+type information at a known offset in method tables.
 <P>
 The collector uses a two level allocator.  A large block is defined to
 be one larger than half of <TT>HBLKSIZE</tt>, which is a power of 2,
@@ -175,6 +181,32 @@ for a single pool of physical memory.
 
 <H2>Mark phase</h2>
 
+At each collection, the collector marks all objects that are
+possibly reachable from pointer variables.  Since it cannot generally
+tell where pointer variables are located, it scans the following
+<I>root segments</i> for pointers:
+<UL>
+<LI>The registers.  Depending on the architecture, this may be done using
+assembly code, or by calling a <TT>setjmp</tt>-like function which saves
+register contents on the stack.
+<LI>The stack(s).  In the case of a single-threaded application,
+on most platforms this
+is done by scanning the memory between (an approximation of) the current
+stack pointer and <TT>GC_stackbottom</tt>.  (For Itanium, the register stack
+scanned separately.)  The <TT>GC_stackbottom</tt> variable is set in
+a highly platform-specific way depending on the appropriate configuration
+information in <TT>gcconfig.h</tt>.  Note that the currently active
+stack needs to be scanned carefully, since callee-save registers of
+client code may appear inside collector stack frames, which may
+change during the mark process.  This is addressed by scanning
+some sections of the stack "eagerly", effectively capturing a snapshot
+at one point in time.
+<LI>Static data region(s).  In the simplest case, this is the region
+between <TT>DATASTART</tt> and <TT>DATAEND</tt>, as defined in
+<TT>gcconfig.h</tt>.  However, in most cases, this will also involve
+static data regions associated with dynamic libraries.  These are
+identified by the mostly platform-specific code in <TT>dyn_load.c</tt>.
+</ul> 
 The marker maintains an explicit stack of memory regions that are known
 to be accessible, but that have not yet been searched for contained pointers.
 Each stack entry contains the starting address of the block to be scanned,
@@ -182,8 +214,11 @@ as well as a descriptor of the block.  If no layout information is
 available for the block, then the descriptor is simply a length.
 (For other possibilities, see <TT>gc_mark.h</tt>.)
 <P>
-At the beginning of the mark phase, all root segments are pushed on the
-stack by <TT>GC_push_roots</tt>.  If <TT>ALL_INTERIOR_PTRS</tt> is not
+At the beginning of the mark phase, all root segments
+(as described above) are pushed on the
+stack by <TT>GC_push_roots</tt>.  (Registers and eagerly processed
+stack sections are processed by pushing the referenced objects instead
+of the stack section itself.)  If <TT>ALL_INTERIOR_PTRS</tt> is not
 defined, then stack roots require special treatment.  In this case, the
 normal marking code ignores interior pointers, but <TT>GC_push_all_stack</tt>
 explicitly checks for interior pointers and pushes descriptors for target
@@ -479,8 +514,9 @@ if there is low demand for small pointerfree objects.
 We support several different threading models.  Unfortunately Pthreads,
 the only reasonably well standardized thread model, supports too narrow
 an interface for conservative garbage collection.  There appears to be
-no completely portable way to allow the collector to coexist with various Pthreads
-implementations.  Hence we currently support only a few of the more
+no completely portable way to allow the collector
+to coexist with various Pthreads
+implementations.  Hence we currently support only the more
 common Pthreads implementations.
 <P>
 In particular, it is very difficult for the collector to stop all other
@@ -510,6 +546,10 @@ accomplished with <TT># define</tt>'s in <TT>gc.h</tt>
 (really <TT>gc_pthread_redirects.h</tt>), or optionally
 by using ld's function call wrapping mechanism under Linux.
 <P>
+Recent versions of the collector support several facilites to enhance
+the processor-scalability and thread performance of the collector.
+These are discussed in more detail <A HREF="scale.html">here</a>.
+<P>
 Comments are appreciated.  Please send mail to
 <A HREF="mailto:boehm@acm.org"><TT>boehm@acm.org</tt></a> or
 <A HREF="mailto:Hans.Boehm@hp.com"><TT>Hans.Boehm@hp.com</tt></a>