[LLVMdev] CollectorRegistry

[Simon Ask Ulsnes]

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