From 5d4fd4de0441ec63a17dceb6d184de743c5d0b30 Mon Sep 17 00:00:00 2001 From: Ivan Maidanski Date: Fri, 5 Apr 2019 00:34:04 +0300 Subject: [PATCH] Update documentation about the incremental collector support * 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 | 11 ++--------- doc/README.win32 | 2 +- doc/scale.md | 5 +++-- 3 files changed, 6 insertions(+), 12 deletions(-) diff --git a/doc/README.darwin b/doc/README.darwin index 4bc6a53..51f5e2b 100644 --- a/doc/README.darwin +++ b/doc/README.darwin @@ -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 diff --git a/doc/README.win32 b/doc/README.win32 index 48a95fa..a4b9689 100644 --- a/doc/README.win32 +++ b/doc/README.win32 @@ -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. diff --git a/doc/scale.md b/doc/scale.md index 855e04e..6733684 100644 --- a/doc/scale.md +++ b/doc/scale.md @@ -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 -- 2.7.4