[LLVMdev] RFC: Garbage collection infrastructure

Gordon Henriksen gordonhenriksen at mac.com
Mon Aug 27 20:34:30 PDT 2007


LLVMers,

Attached for your review: basic infrastructure for efficient garbage  
collectors. Only enough information is currently gathered to support  
the runtime I'm working with, and -print-gc is currently the only  
consumer of this information.

All collector policies are presently controlled by constants. There  
are no regressions (on darwin-i686) if the feature is left disabled.  
If enabled (EnableGC = true in GC.cpp), the JIT breaks because it  
doesn't support labels.

This obviously needs to be fixed; the collector needs to be turned on  
and off by a policy object. I'm not sure where best to hang that  
object off of, though.

  1. Attach it to Target/Subtarget?
  2. Attach it to Function, like the calling convention?
  3. Attach a whole-new TargetCollector (TargetRuntime?) to the Module?

#1 is simplest, but I think wrong. #2 seems best to me. It would let  
the inliner merge bare code with managed code, or vice versa, but  
avoids the risk of silliness like inlining Java into Ocaml.

Opinions?


Once a decision is made on that, I'll resurrect the shadow stack GC  
to ensure I'm maintaining generality. There exists great variability  
in collectors, so supporting several is important, I think. To support:

   [1] no collector
   [2] ocaml collector
   [3] shadow stack collector
   [4] collectors for concurrent systems
     [4a] zero overhead: safe points are patched to jump into the  
runtime
     [4b] intrusive: code must check a "stop" flag at each safe point
   [5] cooperative collectors, where mutators help with collection
   [6] incremental and generational collectors

I see need for the target-independent code to support the following:

   • Disable GC? [1*]
   • Find safe points in tight loops? [4]
   •    "   at calls? [4]
   •    "   after calls? [2*]
   •    "   before returning? [4]
   • Pad safe points with noops to accommodate a patch? To how many  
bytes? [4a]
   • Allow roots in registers? Otherwise force roots into stack  
slots at safe points [2].

And additionally provide callbacks to:

   • Custom lower gcread/gcwrite intrinsics [5,6]. Otherwise replace  
with plain load/store [2,3*].
   • Custom lower gcroot intrinsics [3*]. Otherwise leave for the  
code generator [2*].
   • Introduce code at safe points [4b].
   • Print assembly for per-function metadata.
   • Print assembly for whole-module metadata [2*].
   • Record collector metadata in a JIT context.

Luckily, only those marked with [*] are current needs. :)


Thanks for your feedback!

Gordon



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070827/018d3d3a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc.2.patch
Type: application/octet-stream
Size: 40296 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070827/018d3d3a/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070827/018d3d3a/attachment-0001.html>


More information about the llvm-dev mailing list