* doc/README.Mac: Fix a typo ("command-line").
* doc/README.amiga: Fix typos ("recommendation", "compiling",
"favorably").
* doc/README.cords: Fix a typo ("and").
* doc/README.macros: Fix a typo ("canceled").
* doc/README.sgi: Fix a typo ("related").
* doc/README.solaris2: Fix a typo ("offset").
* doc/leak.html: Fix a typo ("e.g.").
* doc/overview.html: Fix a typo ("December").
* doc/porting.html: Fix typos ("not supported yet", "signaled",
"not defined yet").
* doc/scale.html: Fix typos ("free", "busy-waiting").
* doc/simple_example.html: Fix a typo ("have not yet").
* tests/test_cpp.cc (main): Fix a typo ("command line") in comment.
Prefix Files to configure the GC sources
----------------------------------------
-The Codewarrior equivalent of commandline compilers -DNAME=X is to use
+The Codewarrior equivalent of command-line compilers -DNAME=X is to use
prefix-files. A TEXT file that is automatically #included before the first byte
of every source file. I used these:
program, and prints out the info when the atexit-handler
is called.
- My reccomendation is to set all this flags, except GC_AMIGA_PRINTSTATS and
+ My recommendation is to set all this flags, except GC_AMIGA_PRINTSTATS and
GC_AMIGA_ONLYFAST.
If your program demands high response-time, you should
GC_AMIGA_RETRY does not seem to slow down much.
Also, when compiling up programs, and GC_AMIGA_FASTALLOC was not defined when
- compilling gc, you can define GC_AMIGA_MAKINGLIB to avoid having these allocation-
+ compiling gc, you can define GC_AMIGA_MAKINGLIB to avoid having these allocation-
functions wrapped. (see gc.h)
Note that GC_realloc must not be called before any of
virtual memory software, and probably similar PD software.
The performance of "gctest" on an Amiga 2630 (68030 @ 25Mhz)
-compares favourably with an HP9000 with similar architecture (a 325
+compares favorably with an HP9000 with similar architecture (a 325
with a 68030 I think).
-----------------------------------------------------------------------
up as highlighted "I"s. Use the UNIX "expand" program first.)
To build the editor, type "make cord/de" in the gc directory.
-Note that CORD_printf iand friends use C functions with variable numbers
+Note that CORD_printf and friends use C functions with variable numbers
of arguments in non-standard-conforming ways. This code is known to
break on some platforms, notably PowerPC. It should be possible to
build the remainder of the library (everything but cordprnt.c) on
NO_CANCEL_SAFE (Posix platforms with threads only) Don't bother trying
to make the collector safe for thread cancellation; cancellation is not
used. (Note that if cancellation is used anyway, threads may end up
- getting cancelled in unexpected places.) Even without this option,
+ getting canceled in unexpected places.) Even without this option,
PTHREAD_CANCEL_ASYNCHRONOUS is never safe with the collector. (We could
argue about its safety without the collector.)
also provide the collector with information it requires.
4) pthread_cond_wait and pthread_cond_timed_wait should be prepared for
-premature wakeups. (I believe the pthreads and realted standards require this
+premature wakeups. (I believe the pthreads and related standards require this
anyway. Irix pthreads often terminate a wait if a signal arrives.
The garbage collector uses signals to stop threads.)
(Note that the latter requires a moderately expensive test in operator
delete.)
-I encountered "symbol <unknown>: offet .... is non-aligned" errors. These
+I encountered "symbol <unknown>: offset .... is non-aligned" errors. These
appear to be traceable to the use of the GNU assembler with the Sun linker.
The former appears to generate a relocation not understood by the latter.
The fix appears to be to use a consistent tool chain. (As a non-Solaris-expert
be saved as part of the object. Leak reports will then also include
this information.
<P>
-Many collector features (<I>e.g</i> stubborn objects, finalization,
+Many collector features (<I>e.g.</i> stubborn objects, finalization,
and disappearing links) are less useful in this context, and are not
fully supported. Their use will usually generate additional bogus
leak reports, since the collector itself drops some associated objects.
and Implementation.
</p><p>
Boehm, H., and D. Chase, <a href="http://www.hboehm.info/gc/papers/boecha.ps.gz">"A Proposal for Garbage-Collector-Safe C Compilation"</a>,
-<i>Journal of C Language Translation 4</i>, 2 (Decemeber 1992), pp. 126-141.
+<i>Journal of C Language Translation 4</i>, 2 (December 1992), pp. 126-141.
</p><p>
<b>Other related information: </b>
</p><p>
<DD>
Should be defined if the stack (or thread stacks) grow towards higher
addresses. (This appears to be true only on PA-RISC. If your architecture
-has more than one stack per thread, and is not already supported, you will
+has more than one stack per thread, and is not supported yet, you will
need to do more work. Grep for "IA64" in the source for an example.)
<DT><TT>STACKBOTTOM</tt>
<DD>
GC_init's frame, incrementing it repeatedly
in small steps (decrement if <TT>STACK_GROWS_UP</tt>), and reading the value
at each location. We remember the value when the first
-Segmentation violation or Bus error is signalled, round that
+Segmentation violation or Bus error is signaled, round that
to the nearest plausible page boundary, and use that as the
stack base.
<DT><TT>DYNAMIC_LOADING</tt>
<P>
For GC7, if your platform supports <TT>getcontext()</tt>, then defining
the macro <TT>UNIX_LIKE</tt> for your OS in <TT>gcconfig.h</tt>
-(if it isn't defined there already) is likely to solve the problem.
+(if it isn't defined there yet) is likely to solve the problem.
otherwise, if you are using gcc, <TT>_builtin_unwind_init()</tt>
will be used, and should work fine. If that is not applicable either,
the implementation will try to use <TT>setjmp()</tt>. This will work if your
seconds. With the simple thread-safe collector,
built with <TT>-DGC_THREADS</tt>, the execution time
increased to 10.3 seconds, or 23.5 elapsed seconds with two clients.
-(The times for the <TT>malloc</tt>/i<TT>free</tt> version
+(The times for the <TT>malloc</tt>/<TT>free</tt> version
with glibc <TT>malloc</tt>
are 10.51 (standard library, pthreads not linked),
20.90 (one thread, pthreads linked),
directly for allocation locking would have been worse still, at
least for older versions of linuxthreads.
With THREAD_LOCAL_ALLOC, we first repeatedly try to acquire the
-lock with pthread_mutex_try_lock(), busy_waiting between attempts.
+lock with pthread_mutex_try_lock(), busy-waiting between attempts.
After a fixed number of attempts, we use pthread_mutex_lock().)
<P>
These measurements do not use incremental collection, nor was prefetching
text contains information about other platforms or scenarios.
It can be skipped, especially on first reading</font>.
<H2>Building the collector</h2>
-If you haven't already so, unpack the collector and enter
+If you have not so yet, unpack the collector and enter
the newly created directory with
<PRE>
tar xvfz gc<version>.tar.gz
}
#elif defined(MACOS)
int main() {
- char* argv_[] = {"test_cpp", "10"}; // MacOS doesn't have a commandline
+ char* argv_[] = {"test_cpp", "10"}; // MacOS doesn't have a command line
argv = argv_;
argc = sizeof(argv_)/sizeof(argv_[0]);
#else
projects / gc / commitdiff