X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FGarbageCollection.html;h=91768f1e53397a3a2851ae231b947c83f262e7a8;hb=17183ab9737ef0e9933486b8138ab6d1e7efb1f7;hp=c9324859ba9457b23f24df9a2f3f00f609959246;hpb=0adede059ed76940700195342bb5b02c79e58516;p=oota-llvm.git diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html index c9324859ba9..91768f1e533 100644 --- a/docs/GarbageCollection.html +++ b/docs/GarbageCollection.html @@ -151,7 +151,7 @@ support accurate garbage collection.
LLVM's intermediate representation provides garbage -collection intrinsics which offer support for a broad class of +collection intrinsics that offer support for a broad class of collector models. For instance, the intrinsics permit:
The SemiSpace runtime implements with the suggested -runtime interface and is compatible the ShadowStack backend.
+The SemiSpace runtime implements the suggested +runtime interface and is compatible with the ShadowStack backend.
SemiSpace is a very simple copying collector. When it starts up, it allocates two blocks of memory for the heap. It uses a simple bump-pointer @@ -321,7 +321,7 @@ may use load and store instead of llvm.gcread and
@@ -351,12 +351,12 @@ specified by the runtime.The gc function attribute is used to specify the desired collector -algorithm to the compiler. It is equivalent to specify the collector name +algorithm to the compiler. It is equivalent to specifying the collector name programmatically using the setCollector method of Function.
Specifying the collector on a per-function basis allows LLVM to link together -programs which use different garbage collection algorithms.
+programs that use different garbage collection algorithms.The llvm.gcroot intrinsic is used to inform LLVM of a pointer -variable on the stack. The first argument must be an alloca instruction +variable on the stack. The first argument must be a value referring to an alloca instruction or a bitcast of an alloca. The second contains a pointer to metadata that should be associated with the pointer, and must be a constant or global value address. If your target collector uses tags, use a null pointer for @@ -399,7 +399,7 @@ Entry: ;; Tell LLVM that the stack space is a stack root. ;; Java has type-tags on objects, so we pass null as metadata. %tmp = bitcast %Object** %X to i8** - call void %llvm.gcroot(%i8** %X, i8* null) + call void @llvm.gcroot(i8** %X, i8* null) ... ;; "CodeBlock" is the block corresponding to the start @@ -439,16 +439,16 @@ object). Accordingly, these intrinsics take both pointers as separate arguments for completeness. In this snippet, %object is the object pointer, and %derived is the derived pointer:
-;; An array type. ++ %derived = getelementptr %object, i32 0, i32 2, i32 %n+ ;; An array type. %class.Array = type { %class.Object, i32, [0 x %class.Object*] } -... + ... ;; Load the object pointer from a gcroot. %object = load %class.Array** %object_addr ;; Compute the derived pointer. - %derived = getelementptr %obj, i32 0, i32 2, i32 %n
The LLVM garbage collectors are capable of supporting all of these styles of language, including ones that mix various implementations. To do this, it allows the source-language to associate meta-data with the stack roots, and the heap tracing routines can propagate the +href="#gcroot">stack roots, and the heap tracing routines can propagate the information. In addition, LLVM allows the front-end to extract GC information in any form from a specific object pointer (this supports situations #1 and #3).