search for: llvm_cg_walk_gcroots

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

...: http://llvm.org/docs/GarbageCollection.html I was wondering recently: are there actually any projects that are using these facilities? Preferably ones that I could take a look at? > Based on this, you annotate the variables with llvm.gcroot intrinsics, and > then walk the stack with the llvm_cg_walk_gcroots function. Note that > these are not well tested and probably have holes in them, but these are > the interfaces we want to use :) How is this function actually implemented? Is there special stack-walking code emitted or does LLVM keep an extra stack of roots? Cheers, Carl Friedrich Bol...

...ntract is specific to the current ocaml code generator. In the LLVM world, you should use the first-class support we already have for accurate GC: http://llvm.org/docs/GarbageCollection.html Based on this, you annotate the variables with llvm.gcroot intrinsics, and then walk the stack with the llvm_cg_walk_gcroots function. Note that these are not well tested and probably have holes in them, but these are the interfaces we want to use :) -Chris -- http://nondot.org/sabre/ http://llvm.org/

...e: > 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 llvm/runtime directory. You can copy it into your runtime. > in those methods, how do I access the Collector object instantiated > by LLVM?...

Thanks for the quick reply, Anton. On 2007-08-12, at 16:43, Anton Korobeynikov wrote: > Hello, Gordon. > > Just a quick thinko (that's why I'm sending this e-mail personally): No problem. I hope you don't mind me redirecting back to the list, though… > maybe current infrastructure used for eh/debug info emission can be > extended to handle ocaml data? Perhaps.

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

...vm.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 magic is the llvm_cg_walk_gcroots API function, which provides...

...tml > > Based on this, you annotate the variables with llvm.gcroot intrinsics, I'm totally on board with that. The llvm.gc* intrinsics are well- designed as hooks for runtime-specific code generation. I just need to custom lower llvm.gcroot, too. > and then walk the stack with the llvm_cg_walk_gcroots function. > Note that these are not well tested and probably have holes in > them, but these are the interfaces we want to use :) But here I have to disagree. Quite by design, LLVM lacks an existing runtime to leverage: LLVM � CLR. In light of that, it is difficult to justify ignorin...

...As for the compiler plugin interface, I suggest you ignore it > initially and use the provided shadow-stack option for the time being. > The shadow stack generates significantly suboptimal code, but will let > you avoid writing some platform-specific code. Instead, simply copy > the llvm_cg_walk_gcroots routine from the semispace example. Call it > from your collection routine in order to visit each gcroot on the > runtime stack. > > The shadow stack lets you find roots by automatically emitting a > function prologue and an epilogue to push and pop gcroot entries on a > stac...

...in my language. When I store a variable in GC space, I'll store a char at the beginning of the memory for that variable that simply indicates the type (and I'll be able to infer the size from the type). Given that, I assume I won't ever need use the collector metadata (in @llvm.gcroot, llvm_cg_walk_gcroots, or via CollectorMetadata). Is that right? What does it mean for the plugin to compute a stack map? When are the methods of the plugin called? Who is responsible for calling them? When is the constructor of the plugin called? What is the relationship between the plugin and the GC runtime? In t...

...of the alloca. As for the compiler plugin interface, I suggest you ignore it initially and use the provided shadow-stack option for the time being. The shadow stack generates significantly suboptimal code, but will let you avoid writing some platform-specific code. Instead, simply copy the llvm_cg_walk_gcroots routine from the semispace example. Call it from your collection routine in order to visit each gcroot on the runtime stack. The shadow stack lets you find roots by automatically emitting a function prologue and an epilogue to push and pop gcroot entries on a stack as the program runs. Thi...

...you annotate the variables with llvm.gcroot intrinsics, > > I'm totally on board with that. The llvm.gc* intrinsics are well-designed as > hooks for runtime-specific code generation. I just need to custom lower > llvm.gcroot, too. Yep. >> and then walk the stack with the llvm_cg_walk_gcroots function. Note that >> these are not well tested and probably have holes in them, but these are >> the interfaces we want to use :) > > But here I have to disagree. Quite by design, LLVM lacks an existing runtime > to leverage: LLVM � CLR. In light of that, it is difficult...

...ly identify the live > roots within fun's stack frame at runtime—so long as fun is paused at > the safe point, which it must be if it is not the topmost stack frame. How do you get the info for the non-topmost stack frames in this case? Am I going to need to implement my own version of llvm_cg_walk_gcroots() ? My current mad scheme (which I'm not sure will work) for safe points in a multi-threaded environment uses a global POSIX reader/writer lock. Each running thread keeps a read lock on the global lock when it's running. The old-generation collector attempts to acquire a write-lock whe...

...collect(); space = malloc(Actual); /* what happens if it fails again? */ assert(space != NULL); /* abort if still can't allocate after collection */ return space; } void llvm_gc_collect() { /*printf("Garbage collecting!!\n");*/ if (scan != NULL) { BlockHeader *head; llvm_cg_walk_gcroots(defer); head = scan; scan = NULL; reset(); /* 'scan' now contains the list of deferred refs */ for (; head != NULL; head = head->field.next) { free(head); /* FIXME: this should also decrement the ref count of all pointers within * head, which places them in the...

...ementation 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/attachments/20060226/2e53a487/attachment.html>

...x error before '}' token semispace.c:111: error: syntax error before '*' token semispace.c:111: warning: type defaults to 'int' in declaration of 'llvm_gc_root_chain' semispace.c:111: warning: data definition has no type or storage class semispace.c: In function 'llvm_cg_walk_gcroots': semispace.c:114: error: 'StackEntry' undeclared (first use in this function) semispace.c:114: error: (Each undeclared identifier is reported only once semispace.c:114: error: for each function it appears in.) semispace.c:114: error: 'R' undeclared (first use in this function)...

...licitly registering/unregistering root pads with the runtime. Very similar to the paper you cited, although not a stack. C interop does (from macros) use runtime information directly derived from the data/text bracketing symbols I also mentioned. >>> and then walk the stack with the llvm_cg_walk_gcroots function. >>> Note that these are not well tested and probably have holes in >>> them, but these are the interfaces we want to use :) >> >> But here I have to disagree. Quite by design, LLVM lacks an >> existing runtime to leverage: LLVM CLR. In light of...

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

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

...plugin interface, I suggest you ignore it >> initially and use the provided shadow-stack option for the time >> being. The shadow stack generates significantly suboptimal code, >> but will let you avoid writing some platform-specific code. >> Instead, simply copy the llvm_cg_walk_gcroots routine from the >> semispace example. Call it from your collection routine in order to >> visit each gcroot on the runtime stack. >> >> The shadow stack lets you find roots by automatically emitting a >> function prologue and an epilogue to push and pop gcroot e...