2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>:> I'm not sure the purpose of doing so—llvm::Collector (poorly named; > I'm open to suggestions) exists only in the compiler, not at runtime > in the compiled program. You should need access to it at runtime no > more than you might need access to an instance of llvm::TargetMachine.Maybe I don't understand the architecture correctly. This means that the implementation of my collector's data structures (in this case, a few heaps) is supposed to be independent on the subclassed llvm::Collector? I had initially implemented it as class SimonCollector : public llvm::Collector { public: // ... virtual methods from llvm::Collector void* allocate(...) { /* my allocator */ } void collect() { /* ... */ } // etc. }; but actually allocate, collect, etc. aren't supposed to be there, but in some separate structure that is accessed by both my llvm::Collector subclass (or rather, the assembly generated in the lowering passes) and 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 Jul 26, 2008, at 12:14, Simon Ask Ulsnes wrote:> 2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: >> I'm not sure the purpose of doing so—llvm::Collector (poorly named; >> I'm open to suggestions) exists only in the compiler, not at >> runtime in the compiled program. You should need access to it at >> runtime no more than you might need access to an instance of >> llvm::TargetMachine. > > Maybe I don't understand the architecture correctly. > > This means that the implementation of my collector's data structures > (in this case, a few heaps) is supposed to be independent on the > subclassed llvm::Collector?That's correct. llvm::Collector exists to coordinate the compiler and generate code compatible with your GC runtime library. It is not itself part of your GC runtime library.> I had initially implemented it as > > class SimonCollector : public llvm::Collector > { > public: > // ... virtual methods from llvm::Collector > > void* allocate(...) { /* my allocator */ } > void collect() { /* ... */ } > // etc. > }; > > but actually allocate, collect, etc. aren't supposed to be there, > but in some separate structure that is accessed by both my > llvm::Collector subclass (or rather, the assembly generated in the > lowering passes) and llvm_gc_*?Yes.> 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?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 to find them anywhere under llvm/lib. I believe the semispace example in llvm/runtime provides implementations of these interfaces, however. — Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080726/2e4cb174/attachment.html>
Thank you so much for your help! I now have a much clearer idea of how to proceed. :-) This just keeps getting more interesting. - Simon 2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>:> On Jul 26, 2008, at 12:14, Simon Ask Ulsnes wrote: > > 2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: > > I'm not sure the purpose of doing so—llvm::Collector (poorly named; I'm open > to suggestions) exists only in the compiler, not at runtime in the compiled > program. You should need access to it at runtime no more than you might need > access to an instance of llvm::TargetMachine. > > Maybe I don't understand the architecture correctly. > > This means that the implementation of my collector's data structures (in > this case, a few heaps) is supposed to be independent on the subclassed > llvm::Collector? > > That's correct. llvm::Collector exists to coordinate the compiler and > generate code compatible with your GC runtime library. It is not itself part > of your GC runtime library. > > I had initially implemented it as > > class SimonCollector : public llvm::Collector > { > public: > // ... virtual methods from llvm::Collector > > void* allocate(...) { /* my allocator */ } > void collect() { /* ... */ } > // etc. > }; > > but actually allocate, collect, etc. aren't supposed to be there, but in > some separate structure that is accessed by both my llvm::Collector subclass > (or rather, the assembly generated in the lowering passes) and llvm_gc_*? > > Yes. > > 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? > > 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 to find them anywhere under llvm/lib. I believe the semispace example > in llvm/runtime provides implementations of these interfaces, however. > — Gordon > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >