]> granicus.if.org Git - gc/commitdiff
Update documentation about the incremental collector support
authorIvan Maidanski <ivmai@mail.ru>
Thu, 4 Apr 2019 21:34:04 +0000 (00:34 +0300)
committerIvan Maidanski <ivmai@mail.ru>
Thu, 4 Apr 2019 21:41:51 +0000 (00:41 +0300)
* doc/README.darwin (Important Usage Notes): Remove outdated note about
flaky incremental mode.
* doc/README.darwin (Implementation Information): Remove information
about old incremental collector implementation.
* doc/README.win32 (Watcom compiler): Refine information about the
incremental mode support.
* doc/scale.md (Options for enhanced scalability): Refine when the
dedicated marker threads are created.

doc/README.darwin
doc/README.win32
doc/scale.md

index 4bc6a538eec83fb374264135481c7f481d2743e0..51f5e2b3cbc06824f950b20939b83a2f7ccda27b 100644 (file)
@@ -36,11 +36,6 @@ if you have an application or set of libraries that all use the
 garbage collector, to create an initialization routine for each of
 them that calls GC_INIT(). Better safe than sorry.
 
-The incremental collector is still a bit flaky on darwin. It seems to
-work reliably with workarounds for a few possible bugs in place however
-these workaround may not work correctly in all cases. There may also
-be additional problems that I have not found.
-
 Thread-local GC allocation will not work with threads that are not
 created using the GC-provided override of pthread_create(). Threads
 created without the GC-provided pthread_create() do not have the
@@ -76,10 +71,8 @@ programs that use JNI. If you run code that does not follow the stack
 layout or stack pointer conventions laid out in the PPC Mach-O ABI,
 then this will likely crash the garbage collector.
 
-The original incremental collector support unfortunately no longer works
-on recent Darwin versions. It also relied on some undocumented kernel
-structures. Mach, however, does have a very clean interface to exception
-handing. The current implementation uses Mach's exception handling.
+Mach has a very clean interface to exception handing. So, the current
+implementation of the incremental collection uses Mach's exception handling.
 
 Much thanks goes to Andrew Stone, Dietmar Planitzer, Andrew Begel,
 Jeff Sturm, and Jesse Rosenstock for all their work on the
index 48a95fa2c12b0f180fcb7ec2e5d3423e9add3570..a4b968908e5295f8f1e62a9e15fb47a2a6ae1836 100644 (file)
@@ -116,7 +116,7 @@ Note that all compilations were done under Windows 95 or NT.
 For unknown reason compiling under Windows 3.11 for NT (one
 attempt has been made) leads to broken executables.
 
-Incremental collection is not supported.
+Incremental collection is supported (except for MSDOS and OS/2).
 
 cord is not ported.
 
index 855e04ebe2f6fd199f3b14dae0a9463ab4f7cfb6..673368484c938b32815e6d1ed2905db4b903426d 100644 (file)
@@ -38,8 +38,9 @@ to Makefile.direct again.)
   collector itself, though not the allocation process. Currently the marking
   is performed by the thread that triggered the collection, together with
   _N_ - 1 dedicated threads, where _N_ is the number of processors (cores)
-  detected by the collector. The dedicated marker threads are created once at
-  initialization time. Another effect of this flag is to switch to a more
+  detected by the collector. The dedicated marker threads are created at
+  initialization time (and optionally recreated in child processes after
+  forking). Another effect of this flag is to switch to a more
   concurrent implementation of `GC_malloc_many`, so that free lists can be
   built and memory can be cleared by more than one thread concurrently.
   * Building the collector with `-DTHREAD_LOCAL_ALLOC` adds support for