search for: llvm_gc_collect

We are trying to start an explicit garbage collect by calling llvm_gc_collect(). We have the function declared in GCInterface.h with the following lines: #ifdef __cplusplus #define C_LINKAGE extern "C" #else #define C_LINKAGE #endif C_LINKAGE void llvm_gc_initialize(unsigned InitialHeapSize); C_LINKAGE void llvm_gc_collect(); and I can see it in the gc byte code,...

...the shadow collector lib or perhaps the -l options needed to link my sample (not even to point where I'm figuring out GC actually as I can't link). Not sure this IR is correct but here is what I've been playing with (gc.ll): declare void @llvm.gcroot(i8 **, i8*) declare void @llvm_gc_collect() define void @foo() gc "shadow-stack" { ; int *pa = malloc(sizeof(int)); %a = malloc i32 %pa = alloca i32* store i32* %a, i32** %pa %c = bitcast i32** %pa to i8** call void @llvm.gcroot(i8** %c, i8* null) ; *pa = 99; %t0 = add i32 99,0 %t1 = load i32*...

...ted to be able to use the GC from a C >> frontend (presumably by using llvm_gc_allocate?), do the C functions >> need this attribute as well? > > Yes. I forgot I still needed an answer to my original question. :-P So, I have to implement llvm_gc_initialize, llvm_gc_allocate, and llvm_gc_collect (llvm_cg_walk_gcroots is provided by the Collector framework, right?) -- in those methods, how do I access the Collector object instantiated by LLVM? (It appears I do have to implement them myself, since otherwise there are unresolved symbols when I call them directly from my IR) - Simon

...es in a GC.c file and the generated machine code. If I can get that last explicit link, I'm off to the races. Anybody? My IR doesn't seem to have any roots, even though I've allocated an int and declared a ptr on the stack. declare void @llvm.gcroot(i8 **, i8*) declare void @llvm_gc_collect() declare i32* @llvm_gc_allocate(i32) declare void @llvm_gc_initialize(i32) define void @foo() gc "shadow-stack" { ; int *pa = malloc(sizeof(int)); %a = call i32* @llvm_gc_allocate(i32 4) %pa = alloca i32* store i32* %a, i32** %pa %c = bitcast i32** %pa to i8**...

..., it requires front-end information regarding the layout of pointers within a block in order to fully trace the reference graph. Or am I missing something? Is semispace a drop-in for any front-end that utilizes the llvm.gc* intrinsics? 1a. Semispace isn't actually complete/working is it? Its llvm_gc_collect() implementation doesn't actually seem to do anything, ie. no copying, no space switching, etc. :-) 2. Are there any GC tests available that I can use to test a GC implementation? 3. The description for llvm.gcroot (http://llvm.cs.uiuc.edu/docs/GarbageCollection.html#roots) indicates it's...

...ocess_root[0x0xbffff3f0] = 0x0x41257008 process_root[0x0xbffff3ec] = 0x0x41257012 lli((anonymous namespace)::PrintStackTrace()+0x1a)[0x857f236] lli((anonymous namespace)::SignalHandler(int)+0xcb)[0x857f4a9] [0xffffe420] lli(llvm::ExecutionEngine::runFunctionAsMain... Which is too be expected since llvm_gc_collect in llvm/runtime/GC/SemiSpace/semispace.c ends with abort(); I believe we have our work cut out for us. Hopefully you'll have a working GC by Christmas time. Tom -- 28 70 20 71 2C 65 29 61 9C B1 36 3D D4 69 CE 62 4A 22 8B 0E DC 3E mailto:tdbrown at uiuc.edu http://thecap.org/

...er want to inline the * slow path. */ void *llvm_gc_allocate(unsigned Size) __attribute__((always_inline)); static void* llvm_gc_alloc_slow(unsigned Size) __attribute__((noinline)); void *llvm_gc_allocate(unsigned Size) { unsigned Actual = Size + sizeof(BlockHeader); if (scan != NULL) { llvm_gc_collect(); /* run a bounded collection before every allocation */ } BlockHeader *space = (BlockHeader *)malloc(Actual); if (space == NULL) { space = llvm_gc_alloc_slow(Actual); } space->field.count = 0; /*advance the pointer past the object refcount*/ return (space + sizeof(BlockHeader...

Again, sorry for the delay. :( On Thu, 9 Mar 2006, Sandro Magi wrote: > I've written a reference-counting garbage collector for LLVM, but I'm > still unclear on a few things. Cool! > The following piece of code that appears on > http://llvm.cs.uiuc.edu/docs/GarbageCollection.html is unclear: > > ;; As the pointer goes out of scope, store a null value into > ;;

On Jul 26, 2008, at 10:32, Simon Ask Ulsnes wrote: > I forgot I still needed an answer to my original question. :-P > > So, I have to implement llvm_gc_initialize, llvm_gc_allocate, and > llvm_gc_collect Yes. Your implementation of the llvm_gc_* functions should be compiled into a library and linked with your executable. > (llvm_cg_walk_gcroots is provided by the Collector framework, right?) An implementation of llvm_cg_walk_gcroots compatible with ShadowStackCollector is provided in the...

On 2008-07-23, at 11:48, Simon Ask Ulsnes wrote: > Thank you for that clarification. > >> The framework decides which Collector to use based upon the 'gc' >> attribute of a function: >> >> define void @f() gc "mygc" { >> ... >> } > > OK, so for instance if I wanted to be able to use the GC from a C > frontend (presumably by

...gt; I restart using projects/sample/. Okay, sounds good. Running linked.bc outputs > Garbage collecting!! > process_root[0x0xbffff3f0] = 0x0x41257008 > process_root[0x0xbffff3ec] = 0x0x41257012 > lli(llvm::ExecutionEngine::runFunctionAsMain... > > Which is too be expected since llvm_gc_collect in > llvm/runtime/GC/SemiSpace/semispace.c ends with abort(); > I believe we have our work cut out for us. Hopefully you'll have a > working GC by Christmas time. Yes, indeed :) That would be great! Thanks! :) -Chris -- http://llvm.org/ http://nondot.org/sabre/

Hi Chris, Chris Lattner wrote: > I don't think you want to try to have the LLVM code generator build this > table. The table is a contract between the specific codegen you're using > and the GC runtime you're using. This contract is specific to the current > ocaml code generator. > > In the LLVM world, you should use the first-class support we already have

On Mon, 27 Feb 2006, Sandro Magi wrote: > Couple of questions: Ok, it's been a long while since I've worked on the GC stuff, but I'll try to help :) > 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) > > I haven't seen an adequate explanation of these, but I'm guessing: > void *V: value being written to the field > void *ObjPtr: current value

Thank you for that clarification. > The framework decides which Collector to use based upon the 'gc' > attribute of a function: > > define void @f() gc "mygc" { > ... > } OK, so for instance if I wanted to be able to use the GC from a C frontend (presumably by using llvm_gc_allocate?), do the C functions need this attribute as well? And if so, can this

On Tue, 26 Oct 2004, Tom Brown wrote: > I'm in a group tasked with improving the GC of LLVM for a 421 project. > We are having trouble getting started with the given SemiSpace > collector. > > We found the string llvm_gc_initialize called from a single source file > ./test/Regression/CodeGen/Generic/GC/alloc_loop.ll > which we tried with the following... (showing LLVM

I'm in a group tasked with improving the GC of LLVM for a 421 project. We are having trouble getting started with the given SemiSpace collector. We found the string llvm_gc_initialize called from a single source file ./test/Regression/CodeGen/Generic/GC/alloc_loop.ll which we tried with the following... (showing LLVM checked out from cvs a few days ago, similar output with release 1.3) $

Couple of questions: 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) I haven't seen an adequate explanation of these, but I'm guessing: void *V: value being written to the field void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr upon entry to llvm_gc_write) void **FieldPtr: address of the field being written 2. The current semispace collector includes

...void *. I don't really understand what happens when I generate an @llvm.gcroot intrinsic. Conceptually, I'm announcing that I have a variable that could serve as a GC root. But what exactly is happening? And do I need to care what's happening? Now, back to the collector runtime... When llvm_gc_collect is called, I need to walk through the GC space, starting with the GC roots. How do I get access to the GC roots? Then there is the collector plugin. I guess there will be a MyCustomCollector which inherits from Collector . I really don't understand what this class does and why I need it. Let...

Hi Terence, I think you're getting hung up on the details of the shadow stack collector. The shadow stack is a GC that is possible within this framework, but of course could be implemented without any special support. Its presence is more misleading than anything else. Taking a step back, the concepts are: llvm.gcroot instructs the code generator --> My GC needs to be able to

On Apr 20, 2008, at 6:52 PM, Gordon Henriksen wrote: > On 2008-04-20, at 21:05, Terence Parr wrote: > >> On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote: >> >>> Since the semispace heap doesn't actually work (it's an example, >>> at best), I suggest you simply copy the stack visitor into your >>> project; it's only a dozen lines of