From aab3aff97bc536dca831b45a3a4dc541ae2b51fc Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Wed, 9 Jun 2004 03:59:05 +0000 Subject: [PATCH] Minor tweaks git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14081 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/GarbageCollection.html | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html index 35bb60a598f..3263fc624b0 100644 --- a/docs/GarbageCollection.html +++ b/docs/GarbageCollection.html @@ -220,7 +220,7 @@ CodeBlock:

The llvm_gc_allocate 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.

@@ -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.

+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.

To support garbage collectors that use read or write barriers, LLVM provides the llvm.gcread and llvm.gcwrite intrinsics. The first