search for: llvm_gc_allocate

2008/7/24 Gordon Henriksen <gordonhenriksen at me.com>: >> 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? > > 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 t...

...ou 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 attribute be applied to functions in bitcode compiled by llvm-gcc, without modifications to the C compiler or the output bitcode? I.e., I use a custom driver program similar to lli that loads in bitcode and my GC, and executes...

...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? Yes. > And if so, can this attribute be applied to functions in bitcode > compiled by llvm-gcc, without modifications to the C compiler or the > output bitcode? > I.e., I use a custom driver program similar to lli that load...

...d llvm_gc_*? If that is the case, then I agree, it's a poor name -- at least it got me confused. :-P It's hard to come up with good alternatives, though. Hmm. I looked a bit at the ShadowStackCollector class, and suddenly it makes much more sense. But I fail to find any implementations of llvm_gc_allocate and friends? - Simon

On Thu, 28 Oct 2004, Tom Brown wrote: > We have a few questions about the current state of GC. Ok. :) > We decided to start (and finish?) our work by finishing SemiSpace. Sounds good. > process_pointer is meant to move objects from CurSpace to OtherSpace. > How can it find pointers to a moved object? This is entirely up to you, as you're basically implementing the semispace

...s. Since this is a simple copying collector, the functions llvm_gc_read and llvm_gc_write won't really do much: void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return *FieldPtr; } void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) { *FieldPtr = V; } There is also a function called llvm_gc_allocate. Now, instead of using alloca or malloc, my frontend generates a call to llvm_gc_allocate. Up to this point I feel pretty good about what's going on. But now things get a bit fuzzy. I somehow need to inform the garbage collection runtime (my copycollector.c) about my variables - specifically...

LLVM has GC possibility (llvm_gc_allocate). What compiler uses it? I try ldc D compiler but it not uses LLVM garbage collection but own in Tango library. -- View this message in context: http://old.nabble.com/How-start-with-LLVM-garbage-collector--tp29505874p29505874.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

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

We have a few questions about the current state of GC. We decided to start (and finish?) our work by finishing SemiSpace. process_pointer is meant to move objects from CurSpace to OtherSpace. How can it find pointers to a moved object? How does it know the size of each object? Assuming we are writing a GC that will only work from llvm assembly our best option seems to be forcing the assembly code

...rated 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** call void @llvm.gcroot(i8** %c, i...

...en I agree, it's a poor name -- at least it > got me confused. :-P It's hard to come up with good alternatives, > though. Hmm. > > I looked a bit at the ShadowStackCollector class, and suddenly it > makes much more sense. But I fail to find any implementations of > llvm_gc_allocate and friends? llvm_gc_* are optional interfaces. If you want your allocation routines to look different, then you're free to do so. I consider that section of the document deprecated to obsolete. That said, they're not implemented by the Collector class, so you shouldn't expect...

...LLVM IR code for a program, it should also > generate a call (early in the IR code) to llvm_gc_initialize. This > function uses the system calloc to allocate two big blocks of memory, > then stores pointers to that memory in static variables. > [...] > There is also a function called llvm_gc_allocate. Now, instead of > using alloca or malloc, my frontend generates a call to > llvm_gc_allocate. These function names are entirely optional. Your runtime can use any names and prototypes it likes to provide this functionality. A bump- ptr allocator might easily inline part of its allocation...

...it unclear how big something is; it's >= size of elements like i32 but how much bigger than packed struct is it? I.e., %struct.A = type {i32 x, [10 x i32]*} define void @foo() gc "shadow-stack" { %s = alloca %struct.A ; this knows how big struct.A is %a = call i32* @llvm_gc_allocate(i32 11); this does not know. is it 11 or more? ret void } > You've > got 3 options here… > > • If you have an type tree (as in Java or .NET), you can assume that > every root starts with a pointer to object metadata, which should > naturally include GC tracing informat...

...Specifically: i32 ptrtoint(gep %mytype* null, i32 0, i32 ??? to i32) Where ??? is the number of the field within the struct. (Could be a list of indices.) > 2. How do I know how big a struct is? I have my gc_allocate() method Note: There's absolutely nothing special about the name @llvm_gc_allocate, it's just a gentle suggestion. In fact, if you're using the "model 1" heap tracing strategy, you probably want to use something like this: %class.object* @alloc_object(%runtime.class* %vtable, i32 %nbytes) This way, the vtable pointer is guaranteed to be initialized before...

...(scan, header); /* if refcount is 0, schedule obj to be collected */ SET_POINTER(header); } } } /* llvm_gc_initialize - do nothing */ void llvm_gc_initialize(unsigned InitialHeapSize) { } /* We always want to inline the fast path, but never 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 all...

On 2008-07-23, at 08:58, Simon Ask Ulsnes wrote: > I am attempting to write a garbage collector for LLVM, and the tiny > example in the docs at http://llvm.org/releases/2.3/docs/GarbageCollection.html > gives this line: > > CollectorRegistry::Add<MyCollector> > X("mygc", "My bespoke garbage collector."); > > My question is now: Am I

...at is the case, then I agree, it's a poor name -- at least it got me > confused. :-P It's hard to come up with good alternatives, though. Hmm. > > I looked a bit at the ShadowStackCollector class, and suddenly it makes much > more sense. But I fail to find any implementations of llvm_gc_allocate and > friends? > > llvm_gc_* are optional interfaces. If you want your allocation routines to > look different, then you're free to do so. I consider that section of the > document deprecated to obsolete. > That said, they're not implemented by the Collector class, so you...

Hey, I am a bit confused about the CollectorRegistry. I am attempting to write a garbage collector for LLVM, and the tiny example in the docs at http://llvm.org/releases/2.3/docs/GarbageCollection.html gives this line: CollectorRegistry::Add<MyCollector> X("mygc", "My bespoke garbage collector."); My question is now: Am I supposed to instantiate my collector

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 > ;;

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