* 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.
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.)
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)`
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.)
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
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).
-
------------------------------------------------------------------------
}
- 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
(`-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.
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
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
/* 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
/* 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 */
/* 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
# 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)
# 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 */
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, ...)
# 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
/* 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)
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;
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 */
# 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);
# 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. */
projects / gc / commitdiff