diff options
| author | Chris Lattner <sabre@nondot.org> | 2004-06-09 03:59:05 +0000 |
|---|---|---|
| committer | Chris Lattner <sabre@nondot.org> | 2004-06-09 03:59:05 +0000 |
| commit | aab3aff97bc536dca831b45a3a4dc541ae2b51fc (patch) | |
| tree | be0b69b189ba810f7ca7b9163e3adbe9b0aa8c7e | |
| parent | 1a8c917ec67d0dbc5015641e34da998b0780be70 (diff) | |
Minor tweaks
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14081 91177308-0d34-0410-b5e6-96231b3b80d8
| -rw-r--r-- | docs/GarbageCollection.html | 7 |
1 files changed, 4 insertions, 3 deletions
diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html index 35bb60a598..3263fc624b 100644 --- a/docs/GarbageCollection.html +++ b/docs/GarbageCollection.html @@ -220,7 +220,7 @@ CodeBlock: </tt></div> <p>The <tt>llvm_gc_allocate</tt> function is a global function defined by the -garbage collector implementation to allocate memory. It should return a +garbage collector implementation to allocate memory. It returns a zeroed-out block of memory of the appropriate size.</p> </div> @@ -242,8 +242,9 @@ collectors) need to be informed when the mutator (the program that needs garbage collection) reads or writes object references into the heap. In the case of a generational collector, it needs to keep track of which "old" generation objects have references stored into them. The amount of code that typically needs to be -executed is usually quite small, so the overall performance impact of the -inserted code is tolerable.</p> +executed is usually quite small (and not on the critical path of any +computation), so the overall performance impact of the inserted code is +tolerable.</p> <p>To support garbage collectors that use read or write barriers, LLVM provides the <tt>llvm.gcread</tt> and <tt>llvm.gcwrite</tt> intrinsics. The first |