llvm dev - Oct 2013 - [LLVMdev] Interfacing llvm with a precise, relocating GC

With regard to Bartlett-style collectors, they are also used in CMUCL/SBCL,
OpenDylan, and various products based on Ravenbrook's Memory Pool System.
Also, while Mono doesn't use a Bartlett-style collector, it does support
pinning objects referenced from ambiguous stack roots, in an otherwise
copying collector. While ITA has expressed concerns with SBCL's GC, they
seem to involve the kind of problems copying collectors generally face with
huge heaps, not anything particular to conservative stack scanning. In any
case, people interested in the trade-offs involved might want to talk to
people involved with these projects about their experiences.

Also, it is probably possible to support a more-precise method of stack
scanning without additional support from LLVM. I bet the method of this
paper: http://www.cs.kent.ac.uk/pubs/2009/3128/content.pdf, could be
implemented more directly in LLVM using the exception handling framework
and a custom stack walker. The basic idea would be to generate code in a
landing pad to save the values (but not the addresses) of live roots to
some memory location. Instead of call instructions, the front-end emits
invoke instructions that can branch to that landing pad. During GC, a
custom stack walker can walk up the stack and call the code in the landing
pads to gather roots, without unwinding the stack. This approach allows
LLVM to promote roots to SSA values, and encodes the right semantics: it's
okay to create derived roots across a call (safepoint) so long as the
original value is available for the landing pad. It does not allow the
values to be changed during GC, but at least addresses the concern of false
retention from ambiguous roots.

It should be possible, if somewhat more difficult, to generate landing pads
that merge control flow back to the non-exceptional case, after reloading
the values of roots from some memory location. This approach expresses the
data-flow semantic that the values of roots may be reloaded from memory
across a call. The tricky part with this approach is how to express to
handle the fact that LLVM's invoke instruction only defines a value along
the non-exceptional edge. But I'm sure there is some cleverness that could
address that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131030/de5f1cbd/attachment.html>

> On Oct 30, 2013, at 8:22 AM, Rayiner Hashem <rayiner at gmail.com>
wrote:
> 
> With regard to Bartlett-style collectors, they are also used in CMUCL/SBCL,
OpenDylan, and various products based on Ravenbrook's Memory Pool System.
Also, while Mono doesn't use a Bartlett-style collector, it does support
pinning objects referenced from ambiguous stack roots, in an otherwise copying
collector. While ITA has expressed concerns with SBCL's GC, they seem to
involve the kind of problems copying collectors generally face with huge heaps,
not anything particular to conservative stack scanning. In any case, people
interested in the trade-offs involved might want to talk to people involved with
these projects about their experiences.
> 
> Also, it is probably possible to support a more-precise method of stack
scanning without additional support from LLVM. I bet the method of this paper:
http://www.cs.kent.ac.uk/pubs/2009/3128/content.pdf, could be implemented more
directly in LLVM using the exception handling framework and a custom stack
walker. The basic idea would be to generate code in a landing pad to save the
values (but not the addresses) of live roots to some memory location. Instead of
call instructions, the front-end emits invoke instructions that can branch to
that landing pad. During GC, a custom stack walker can walk up the stack and
call the code in the landing pads to gather roots, without unwinding the stack.
This approach allows LLVM to promote roots to SSA values, and encodes the right
semantics: it's okay to create derived roots across a call (safepoint) so
long as the original value is available for the landing pad. It does not allow
the values to be changed during GC, but at least addresses the concern of false
retention from ambiguous roots.
Thanks for the shout-out. It is interesting to note that the approach where we
used branch-after-call to implement exceptions explicitly and then used them for
both GC and the source language exceptions was even better than try/catch, at
least with gcc as the backend. This trivially allows both copying for roots and
register allocation.

Of course it was still slower than Bartlett. 
> 
> It should be possible, if somewhat more difficult, to generate landing pads
that merge control flow back to the non-exceptional case, after reloading the
values of roots from some memory location. This approach expresses the data-flow
semantic that the values of roots may be reloaded from memory across a call. The
tricky part with this approach is how to express to handle the fact that
LLVM's invoke instruction only defines a value along the non-exceptional
edge. But I'm sure there is some cleverness that could address that.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131030/9fc133b7/attachment.html>