From: Ivan Maidanski Date: Fri, 22 Mar 2019 16:44:35 +0000 (+0300) Subject: Use KB/MB/GB abbreviations uniformly across entire documentation X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=07c056c3291f04c82533fe42bb14be8420167db8;p=gc Use KB/MB/GB abbreviations uniformly across entire documentation * README.md (Installation and Portability): Precede MB with a space. * doc/README.amiga (WHATS NEW): Likewise. * doc/debugging.md: Likewise. * README.md (The C Interface to the Allocator): Replace Kbytes to KB. * doc/gc.man: Likewise. * README.Mac: Replace k to KB with a preceding space. * doc/debugging.md: Likewise. * doc/README.amiga: Precede MHz with a space. * doc/debugging.md: Precede KB with a space. * include/gc.h (GC_malloc_ignore_off_page): Replace K to KB with a preceding space in a comment. * tests/test.c (BIG): Likewise. * include/private/gc_priv.h (ALL_INTERIOR_POINTERS, HBLKSIZE, CPP_LOG_HBLKSIZE, LOG_PHT_ENTRIES): Likewise. * include/private/gc_priv.h (LOG_PHT_ENTRIES): Replace M to MB with a preceding space in a comment. * include/private/gc_priv.h (LOG_PHT_ENTRIES): Replace G to GB with a preceding space in a comment. * os_dep.c [GC_USE_MEM_TOP_DOWN && USE_WINALLOC] (GC_mem_top_down): Likewise. * include/gc_priv.h (GC_printf): Replace k to KB with a preceding space in a comment. * include/private/specific.h (quick_thread_id): Likewise. * os_dep.c [MSWINCE] (GC_wince_get_mem): Likewise. * os_dep.c [USE_WINALLOC && !MSWIN_XBOX1 || CYGWIN32] (GC_win32_get_mem): Likewise. * include/private/gcconfig.h [I386 && LINUX] (HEAP_START): Precede GB with a space in a comment. --- diff --git a/README.md b/README.md index ed0bd25d..abd5118d 100644 --- a/README.md +++ b/README.md @@ -203,7 +203,7 @@ useful primarily if you have a machine that's not already supported. Gctest is a somewhat superficial test of collector functionality. Failure is indicated by a core dump or a message to the effect that the collector is broken. Gctest takes about a second to two to run on reasonable 2007 vintage desktops. It may -use up to about 30MB of memory. (The multi-threaded version will use more. +use up to about 30 MB of memory. (The multi-threaded version will use more. 64-bit versions may use more.) `make test` will also, as its last step, attempt to build and test the "cord" string library.) @@ -327,7 +327,7 @@ all of the following, plus many others. the somewhere within the first 256 bytes of the object while it is live. (This pointer should normally be declared volatile to prevent interference from compiler optimizations.) This is the recommended - way to allocate anything that is likely to be larger than 100 Kbytes + way to allocate anything that is likely to be larger than 100 KB or so. (`GC_malloc` may result in failure to reclaim such objects.) 7) `GC_set_warn_proc(proc)` diff --git a/doc/README.Mac b/doc/README.Mac index 3c840d93..f2206d48 100644 --- a/doc/README.Mac +++ b/doc/README.Mac @@ -310,7 +310,7 @@ For your convenience project files for the major Macintosh development systems are provided. For Symantec C++/THINK C, you must build the two projects gclib-1 and -gclib-2. It has to be split up because the collector has more than 32k +gclib-2. It has to be split up because the collector has more than 32 KB of static data and no library can have more than this in the Symantec environment. (Future versions will probably fix this.) diff --git a/doc/README.amiga b/doc/README.amiga index 4447c523..ba051845 100644 --- a/doc/README.amiga +++ b/doc/README.amiga @@ -24,7 +24,7 @@ WHATS NEW: Programs using more time actually using the memory allocated (instead of just allocate and free rapidly) have the most to earn on this, but even gctest now normally runs twice - as fast and uses less memory, on my poor 8MB machine. + as fast and uses less memory, on my poor 8 MB machine. The changes have only effect when there is no more fast-mem left. But with the way GC works, it @@ -279,8 +279,6 @@ THE GOOD NEWS The library as it stands is compatible with the GigaMem commercial virtual memory software, and probably similar PD software. -The performance of "gctest" on an Amiga 2630 (68030 @ 25Mhz) +The performance of "gctest" on an Amiga 2630 (68030 @ 25 MHz) compares favorably with an HP9000 with similar architecture (a 325 with a 68030 I think). - ------------------------------------------------------------------------ diff --git a/doc/debugging.md b/doc/debugging.md index 28626807..10727f27 100644 --- a/doc/debugging.md +++ b/doc/debugging.md @@ -88,7 +88,7 @@ to be permanent, the warning indicates a memory leak. } - 4. In the unlikely case that even relatively small object (<20KB) + 4. In the unlikely case that even relatively small object (<20 KB) 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 @@ -133,11 +133,11 @@ Unexpected heap growth can be due to one of the following: (`-DDONT_ADD_BYTE_AT_END`). The collector rounds up object sizes so the result fits well into the chunk -size (`HBLKSIZE`, normally 4K on 32 bit machines, 8K on 64 bit machines) used -by the collector. Thus it may be worth avoiding objects of size 2K + 1 (or 2K -if a byte is being added at the end.) The last two cases can often -be identified by looking at the output of a call to `GC_dump`. Among other -things, it will print the list of free heap blocks, and a very brief +size (`HBLKSIZE`, normally 4 KB on 32-bit machines, 8 KB on 64-bit ones) used +by the collector. Thus it may be worth avoiding objects of size 2K + 1 bytes +(or exactly 2 KB if a byte is being added at the end.) The last two cases can +often be identified by looking at the output of a call to `GC_dump`. Among +other things, it will print the list of free heap blocks, and a very brief description of all chunks in the heap, the object sizes they correspond to, and how many live objects were found in the chunk at the last collection. @@ -172,8 +172,9 @@ be resolved using one or more of the following techniques: beginning, either try the typed allocation primitives is`gc_typed.h`, or separate out the pointer-free component. 3. Consider using `GC_malloc_ignore_off_page` to allocate large objects. - (See `gc.h` and above for details. Large means >100K in most environments.) - 4. If your heap size is larger than 100MB or so, build the collector with + (See `gc.h` and above for details. Large means more than 100 KB in most + environments.) + 4. If your heap size is larger than 100 MB or so, build the collector with `-DLARGE_CONFIG`. This allows the collector to keep more precise black-list information. 5. If you are using heaps close to, or larger than, a gigabyte on a 32-bit diff --git a/doc/gc.man b/doc/gc.man index aca1fbff..590bf544 100644 --- a/doc/gc.man +++ b/doc/gc.man @@ -63,7 +63,7 @@ GC_malloc_ignore_off_page and .I GC_malloc_atomic_ignore_off_page -inform the collector that the client code will always maintain a pointer to near the beginning of the object (within the first 512 bytes), and that pointers beyond that can be ignored by the collector. This makes it much easier for the collector to place large objects. These are recommended for large object allocation. (Objects expected to be larger than about 100KBytes should be allocated this way.) +inform the collector that the client code will always maintain a pointer to near the beginning of the object (within the first 512 bytes), and that pointers beyond that can be ignored by the collector. This makes it much easier for the collector to place large objects. These are recommended for large object allocation. (Objects expected to be > ~100 KB should be allocated this way.) .LP It is also possible to use the collector to find storage leaks in programs destined to be run with standard malloc/free. The collector can be compiled for thread-safe operation. Unlike standard malloc, it is safe to call malloc after a previous malloc call was interrupted by a signal, provided the original malloc call is not resumed. .LP diff --git a/include/gc.h b/include/gc.h index 5cd39f61..34d128d7 100644 --- a/include/gc.h +++ b/include/gc.h @@ -885,7 +885,7 @@ GC_API int GC_CALL GC_collect_a_little(void); /* it reduces the chance of the allocator not finding space for such */ /* an array, since it will try hard to avoid introducing such a false */ /* reference.) On a SunOS 4.X or MS Windows system this is recommended */ -/* for arrays likely to be larger than 100K or so. For other systems, */ +/* for arrays likely to be larger than 100 KB or so. For other systems,*/ /* or if the collector is not configured to recognize all interior */ /* pointers, the threshold is normally much higher. */ GC_API GC_ATTR_MALLOC GC_ATTR_ALLOC_SIZE(1) void * GC_CALL diff --git a/include/private/gc_priv.h b/include/private/gc_priv.h index 671ebfc9..91a37a86 100644 --- a/include/private/gc_priv.h +++ b/include/private/gc_priv.h @@ -313,7 +313,7 @@ typedef int GC_bool; /* by integers, etc. Under SunOS 4.X with a */ /* statically linked libc, we empirically */ /* observed that it would be difficult to */ - /* allocate individual objects larger than 100K. */ + /* allocate individual objects > 100 KB. */ /* Even if only smaller objects are allocated, */ /* more swap space is likely to be needed. */ /* Fortunately, much of this will never be */ @@ -863,16 +863,16 @@ EXTERN_C_BEGIN /* Heap block size, bytes. Should be power of 2. */ /* Incremental GC with MPROTECT_VDB currently requires the */ /* page size to be a multiple of HBLKSIZE. Since most modern */ -/* architectures support variable page sizes down to 4K, and */ -/* X86 is generally 4K, we now default to 4K, except for */ -/* Alpha: Seems to be used with 8K pages. */ +/* architectures support variable page sizes down to 4 KB, and */ +/* X86 is generally 4 KB, we now default to 4 KB, except for */ +/* Alpha: Seems to be used with 8 KB pages. */ /* SMALL_CONFIG: Want less block-level fragmentation. */ #ifndef HBLKSIZE # if defined(LARGE_CONFIG) || !defined(SMALL_CONFIG) # ifdef ALPHA # define CPP_LOG_HBLKSIZE 13 # elif defined(SN_TARGET_ORBIS) || defined(SN_TARGET_PSP2) -# define CPP_LOG_HBLKSIZE 16 /* page size is set to 64K */ +# define CPP_LOG_HBLKSIZE 16 /* page size is set to 64 KB */ # else # define CPP_LOG_HBLKSIZE 12 # endif @@ -961,27 +961,27 @@ EXTERN_C_BEGIN # ifdef LARGE_CONFIG # if CPP_WORDSZ == 32 # define LOG_PHT_ENTRIES 20 /* Collisions likely at 1M blocks, */ - /* which is >= 4GB. Each table takes */ - /* 128KB, some of which may never be */ + /* which is >= 4 GB. Each table takes */ + /* 128 KB, some of which may never be */ /* touched. */ # else # define LOG_PHT_ENTRIES 21 /* Collisions likely at 2M blocks, */ - /* which is >= 8GB. Each table takes */ - /* 256KB, some of which may never be */ + /* which is >= 8 GB. Each table takes */ + /* 256 KB, some of which may never be */ /* touched. */ # endif # elif !defined(SMALL_CONFIG) # define LOG_PHT_ENTRIES 18 /* Collisions are likely if heap grows */ - /* to more than 256K hblks >= 1GB. */ - /* Each hash table occupies 32K bytes. */ + /* to more than 256K hblks >= 1 GB. */ + /* Each hash table occupies 32 KB. */ /* Even for somewhat smaller heaps, */ /* say half that, collisions may be an */ /* issue because we blacklist */ /* addresses outside the heap. */ # else # define LOG_PHT_ENTRIES 15 /* Collisions are likely if heap grows */ - /* to more than 32K hblks = 128MB. */ - /* Each hash table occupies 4K bytes. */ + /* to more than 32K hblks (128 MB). */ + /* Each hash table occupies 4 KB. */ # endif # define PHT_ENTRIES ((word)1 << LOG_PHT_ENTRIES) # define PHT_SIZE (PHT_ENTRIES >> LOGWL) @@ -1227,12 +1227,12 @@ struct roots { # if defined(PARALLEL_MARK) && (defined(MSWIN32) || defined(CYGWIN32)) # define MAX_HEAP_SECTS 384 # else -# define MAX_HEAP_SECTS 128 /* Roughly 256MB (128*2048*1K) */ +# define MAX_HEAP_SECTS 128 /* Roughly 256 MB (128*2048*1024) */ # endif # elif CPP_WORDSZ > 32 -# define MAX_HEAP_SECTS 1024 /* Roughly 8GB */ +# define MAX_HEAP_SECTS 1024 /* Roughly 8 GB */ # else -# define MAX_HEAP_SECTS 512 /* Roughly 4GB */ +# define MAX_HEAP_SECTS 512 /* Roughly 4 GB */ # endif #endif /* !MAX_HEAP_SECTS */ @@ -2268,7 +2268,7 @@ GC_API void GC_CALL GC_noop1(word); GC_API_PRIV void GC_printf(const char * format, ...) GC_ATTR_FORMAT_PRINTF(1, 2); /* A version of printf that doesn't allocate, */ - /* 1K total output length. */ + /* 1 KB total output length. */ /* (We use sprintf. Hopefully that doesn't */ /* allocate for long arguments.) */ GC_API_PRIV void GC_err_printf(const char * format, ...) diff --git a/include/private/gcconfig.h b/include/private/gcconfig.h index 88dddef0..8f863151 100644 --- a/include/private/gcconfig.h +++ b/include/private/gcconfig.h @@ -1477,7 +1477,7 @@ EXTERN_C_BEGIN # endif # define HEAP_START (ptr_t)0x1000 /* This encourages mmap to give us low addresses, */ - /* thus allowing the heap to grow to ~3GB */ + /* thus allowing the heap to grow to ~3 GB. */ # ifdef __ELF__ # define DYNAMIC_LOADING EXTERN_C_END diff --git a/include/private/specific.h b/include/private/specific.h index ec2ed9b4..348aa41c 100644 --- a/include/private/specific.h +++ b/include/private/specific.h @@ -67,7 +67,7 @@ typedef struct thread_specific_entry { /* only as a backup. */ /* Return the "quick thread id". Default version. Assumes page size, */ -/* or at least thread stack separation, is at least 4K. */ +/* or at least thread stack separation, is at least 4 KB. */ /* Must be defined so that it never returns 0. (Page 0 can't really be */ /* part of any stack, since that would make 0 a valid stack pointer.) */ #define quick_thread_id() (((word)GC_approx_sp()) >> 12) diff --git a/os_dep.c b/os_dep.c index 73b251d8..875eb4b1 100644 --- a/os_dep.c +++ b/os_dep.c @@ -2334,8 +2334,8 @@ void * os2_alloc(size_t bytes) GC_pages_executable ? PAGE_EXECUTE_READWRITE : PAGE_READWRITE); if (HBLKDISPL(result) != 0) ABORT("Bad VirtualAlloc result"); - /* If I read the documentation correctly, this can */ - /* only happen if HBLKSIZE > 64k or not a power of 2. */ + /* If I read the documentation correctly, this can */ + /* only happen if HBLKSIZE > 64 KB or not a power of 2. */ if (GC_n_heap_bases >= MAX_HEAP_SECTS) ABORT("Too many heap sections"); if (result == NULL) return NULL; GC_heap_bases[GC_n_heap_bases] = result; @@ -2370,7 +2370,7 @@ void * os2_alloc(size_t bytes) DWORD GC_mem_top_down = MEM_TOP_DOWN; /* Use GC_USE_MEM_TOP_DOWN for better 64-bit */ /* testing. Otherwise all addresses tend to */ - /* end up in first 4GB, hiding bugs. */ + /* end up in first 4 GB, hiding bugs. */ # else # define GC_mem_top_down 0 # endif /* !GC_USE_MEM_TOP_DOWN */ @@ -2431,7 +2431,7 @@ void * os2_alloc(size_t bytes) # endif /* USE_WINALLOC */ if (HBLKDISPL(result) != 0) ABORT("Bad VirtualAlloc result"); /* If I read the documentation correctly, this can */ - /* only happen if HBLKSIZE > 64k or not a power of 2. */ + /* only happen if HBLKSIZE > 64 KB or not a power of 2. */ if (GC_n_heap_bases >= MAX_HEAP_SECTS) ABORT("Too many heap sections"); if (0 != result) GC_heap_bases[GC_n_heap_bases++] = result; return(result); diff --git a/tests/test.c b/tests/test.c index 67688292..a1ce0bcf 100644 --- a/tests/test.c +++ b/tests/test.c @@ -730,13 +730,13 @@ void *GC_CALLBACK reverse_test_inner(void *data) # if defined(MACOS) \ || (defined(UNIX_LIKE) && defined(NO_GETCONTEXT)) /* e.g. musl */ - /* Assume 128K stacks at least. */ + /* Assume 128 KB stacks at least. */ # define BIG 1000 # elif defined(PCR) - /* PCR default stack is 100K. Stack frames are up to 120 bytes. */ + /* PCR default stack is 100 KB. Stack frames are up to 120 bytes. */ # define BIG 700 # elif defined(MSWINCE) || defined(RTEMS) - /* WinCE only allows 64K stacks */ + /* WinCE only allows 64 KB stacks. */ # define BIG 500 # elif defined(OSF1) /* OSF has limited stack space by default, and large frames. */