search for: gcinterfac

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, $ llvm-nm GC/Generational/Debug/generational.bc...

...115 Verifier.cpp 714,715c714,715 < case Intrinsic::gcread: NumArgs = 1; break; < case Intrinsic::gcwrite: NumArgs = 2; break; --- > case Intrinsic::gcread: NumArgs = 2; break; > case Intrinsic::gcwrite: NumArgs = 3; break; Index: llvm/runtime/GC/GCInterface.h =================================================================== RCS file: /var/cvs/llvm/llvm/runtime/GC/GCInterface.h,v retrieving revision 1.2 diff -r1.2 GCInterface.h 41c41 < void *llvm_gc_read(void **P); --- > void *llvm_gc_read(void **P, unsigned Offset); 46c46 < void llvm_gc_wr...

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In

...t;ty2>* %metadata) I don't see an implementation of the llvm.gcroot intrinsic in the semispace collector, so is it implemented elsewhere? Semispace has a function with the same signature, but it's not in the public GC interface ( http://llvm.cs.uiuc.edu/cvsweb/cvsweb.cgi/llvm/runtime/GC/GCInterface.h). Or is this simply because the llvm_cg_walk_gcroots callback hasn't been refactored as an external interface (as per #2 above)? That's it for now. :-) Sandro

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

...115 Verifier.cpp 714,715c714,715 < case Intrinsic::gcread: NumArgs = 1; break; < case Intrinsic::gcwrite: NumArgs = 2; break; --- > case Intrinsic::gcread: NumArgs = 2; break; > case Intrinsic::gcwrite: NumArgs = 3; break; Index: llvm/runtime/GC/GCInterface.h =================================================================== RCS file: /var/cvs/llvm/llvm/runtime/GC/GCInterface.h,v retrieving revision 1.2 diff -r1.2 GCInterface.h 41c41 < void *llvm_gc_read(void **P); --- > void *llvm_gc_read(void *ObjPtr, void **FieldPtr); 46c46 < void llvm_g...

...t;ty2>* %metadata) I don't see an implementation of the llvm.gcroot intrinsic in the semispace collector, so is it implemented elsewhere? Semispace has a function with the same signature, but it's not in the public GC interface ( http://llvm.cs.uiuc.edu/cvsweb/cvsweb.cgi/llvm/runtime/GC/GCInterface.h). Or is this simply because the llvm_cg_walk_gcroots callback hasn't been refactored as an external interface (as per #2 above)? That's it for now. :-) Sandro -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/at...

...t; > I don't see an implementation of the llvm.gcroot intrinsic in the > semispace collector, so is it implemented elsewhere? Semispace has a > function with the same signature, but it's not in the public GC > interface ( http://llvm.cs.uiuc.edu/cvsweb/cvsweb.cgi/llvm/runtime/GC/GCInterface.h). > Or is this simply because the llvm_cg_walk_gcroots callback hasn't > been refactored as an external interface (as per #2 above)? The llvm.gcroot intrinsic is turned into magic in the code generator that clients aren't supposed to know about. The public interface to this mag...

...aces. The next step in this is to flush out the interface between the GC and the language runtime. The GC doesn't want to know anything about how the FE lays out vtables and GC info, and the front-end doesn't want to know anything about how the GC implements its algorithm. The runtime/GC/GCInterface.h file is a start on this, but the callbacks described above will also need to be added. The next step is to extend alloc_loop to use these interfaces. It might be useful to translate it to C code, to make it easier to deal with. >From there, you can add one feature at a time, iterating betwe...

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

...d' and 'scan' |* (which is now empty) are swapped. |* |* Reference counts are maintained via a write barrier. A collection is run on |* every allocation if 'scan' is not empty. |* \*===----------------------------------------------------------------------===*/ #include "../GCInterface.h" #include <stdio.h> #include <stdlib.h> #include <string.h> #include <assert.h> /* Possible Enhancements: * 1. A full collection of the list is default, and an iteration bound is possible * (for real-time constraints?), but this involves moving elements between *...

..., all variables are allocated by doing an alloca or malloc, then by doing a store of the alloca to the variable. Now let's assume I want to add a simple copying garbage collector. I write an implementation called copycollector.c (based on semispace.c) that implements the functions declared in GCInterface.h. When my frontend generates 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. Since this is a simple copyin...

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

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