Instruction encoding bug
[oota-llvm.git] / docs / GarbageCollection.html
index 35bb60a598f0425ba1b009154fbeca106e836704..91be23967462660e0e5793cc5f9dc0810e67a8c4 100644 (file)
@@ -36,6 +36,7 @@
   <li><a href="#gcimpls">GC implementations available</a>
     <ul>
     <li><a href="#semispace">SemiSpace - A simple copying garbage collector</a></li>
+    </ul>
   </li>
 
 <!--
@@ -220,7 +221,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>
@@ -233,8 +234,8 @@ zeroed-out block of memory of the appropriate size.</p>
 <div class="doc_text">
 
 <div class="doc_code"><tt>
-  sbyte *%llvm.gcread(sbyte **)<br>
-  void %llvm.gcwrite(sbyte*, sbyte**)
+  sbyte *%llvm.gcread(sbyte *, sbyte **)<br>
+  void %llvm.gcwrite(sbyte*, sbyte*, sbyte**)
 </tt></div>
 
 <p>Several of the more interesting garbage collectors (e.g., generational
@@ -242,13 +243,16 @@ 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
 intrinsic has exactly the same semantics as a non-volatile LLVM load and the
-second has the same semantics as a non-volatile LLVM store.  At code generation
+second has the same semantics as a non-volatile LLVM store, with the
+additions that they also take a pointer to the start of the memory
+object as an argument.  At code generation
 time, these intrinsics are replaced with calls into the garbage collector
 (<tt><a href="#llvm_gc_readwrite">llvm_gc_read</a></tt> and <tt><a
 href="#llvm_gc_readwrite">llvm_gc_write</a></tt> respectively), which are then
@@ -339,8 +343,8 @@ implementations</a> available.
 
 <div class="doc_text">
   <div class="doc_code"><tt>
-    void *llvm_gc_read(void **)<br>
-    void llvm_gc_write(void*, void**)
+    void *llvm_gc_read(void*, void **)<br>
+    void llvm_gc_write(void*, void *, void**)
  </tt></div>
 
 <p>
@@ -351,19 +355,22 @@ pointer, then return.
 
 <p>
 If an actual read or write barrier is needed, it should be straight-forward to
-implement it.  Note that we may add a pointer to the start of the memory object
-as a parameter in the future, if needed.
+implement it.
 </p>
 
 </div>
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="callbacks">Callback functions used to implement the garbage collector</a></li>
+  <a name="callbacks">Callback functions used to implement the garbage collector</a>
 </div>
 
+<div class="doc_text">
+<p>
 Garbage collector implementations make use of call-back functions that are
 implemented by other parts of the LLVM system.
+</p>
+</div>
 
 <!--_________________________________________________________________________-->
 <div class="doc_subsubsection">
@@ -459,7 +466,7 @@ collector, etc), or you could choose to improve one of the existing algorithms.
 
 <!-- ======================================================================= -->
 <div class="doc_subsection">
-  <a name="semispace">SemiSpace - A simple copying garbage collector</a></li>
+  <a name="semispace">SemiSpace - A simple copying garbage collector</a>
 </div>
 
 <div class="doc_text">
@@ -518,7 +525,7 @@ conference on LISP and functional programming.</p>
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
 
   <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
-  <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
+  <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
   Last modified: $Date$
 </address>