On Thu, Oct 17, 2013 at 4:45 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Thu, Oct 17, 2013 at 11:31 AM, Ben Karel <[email protected]> wrote: >> >> On Thu, Oct 17, 2013 at 2:02 PM, Jonathan S. Shapiro <[email protected]> >> wrote: >>> >>> Thanks, Ben. >>> >>> From the outside, looking from the GC-inclined perspective, it seems >>> unfortunate that LLVM doesn't have a distinguished register class in the IR >>> for object references as opposed to pointers. This would go a long way >>> toward solving the stack map problem. On the other hand, I haven't thought >>> hard enough about whether the presence of GCREAD/GCWRITE coupled with local >>> dataflow might be enough. >> >> >> What stack map problem? > > > The stack map problem is to keep track of which words on the stack hold > pointers at any given time. It's a map taking as input a PC and an SP and > producing as output a set of frame-relative word offsets for the words that > contain object references. > > Last time I checked, LLVM provided zero assist for this. The solution people > were using was to adopt the threaded-stack approach originally proposed by > Fergus Henderson [*]. In essence, the front end gathers all of the object > references into an on-stack shadow stack, and then arranges to "leak" the > address of the struct outside the procedure. The effect is that any > temporary register containing an object reference becomes non-live at every > procedure call and has to be re-loaded from the struct. This ensures that > there are no live object references in registers at any time when a > collection might occur. > > [*] Fergus Henderson, Accurate Garbage Collection in an Uncooperative > Environment
Have you looked at the documentation? [http://llvm.org/docs/GarbageCollection.html] LLVM offers two basic options for doing accurate collection: 1. the shadow stack approach that you mentioned [http://llvm.org/docs/GarbageCollection.html#about-the-shadow-stack] 2. writing a custom plugin [http://llvm.org/docs/GarbageCollection.html#implementing-a-collector-plugin] In both cases, you are required to mark each GC root explicitly, and all roots must be what LLVM calls "alloca"s (not to be confused with alloca(3)). Marking a location as a root essentially makes it invisible to the mem2reg pass. (That is to say, the alloca -- which basically represents a stack location -- cannot not be promoted to a virtual register in the SSA IR. My understanding is that this makes it invisible to most optimization passes. See the last paragraph of http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-February/038186.html) [http://llvm.org/docs/GarbageCollection.html#gcroot]. LLVM will compute a stack map for you, for any safe point. The binary representation of this map is up to you. [http://llvm.org/docs/GarbageCollection.html#computing-stack-maps] [snip] >> I'm unclear on what you think "no objects in registers" (again, that >> word!) means, or what alternative you have in mind. Could you clarify? And >> also cite the study you have in mind? > > > If you don't know which registers contain object references, you have two > choices: > > Ensure that any object which might be referenced by a register > (conservatively) is not relocated. This precludes mark-compact and generally > makes relocation a pain. I *think* that this is the approach that Mono takes with its LLVM backend. > Ensure that no object references are allowed to remain in registers during a > collection (this is what Henderson is doing). ... and what LLVM requires, even if you don't use the shadow stack. - Jon _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
