On Thu, Apr 7, 2011 at 5:39 PM, Ben Karel <[email protected]> wrote: > As the quote there says, using a shadow stack is the easiest way to get > started with GC in LLVM.
Yes. And since my comments lend themselves to being misread, let me say this more clearly: 1. I think it's *great* that the LLVM sample infrastructure provides a low-overhead point of entry for people who want to play with GC. 2. The presence of any particular bit of sample code certainly does not indicate any flaw in LLVM. > , but it's not really "the default" in any sense except being moderately > easier than designing and writing a plugin to compile stack maps, and > runtime code to walk the stack... This is the place where the problem arises in my mind. I should start by acknowledging that the stack map plugin functionality in LLVM is new, and that I haven't yet tried to explore it in detail. Here are a couple of concerns that I have: 1. Last time I looked, LLVM lacked the capability to produce register type maps at call sites. 2. The LLVM optimization infrastructure does not guarantee type preservation - even low level type preservation - in the optimization process. 3. Last I looked, the LLVM infrastructure did not adequately describe internal pointers in the low-level types. Of these two, the second and third are the larger concerns. Issue [2] is a polite way of saying that people who write optimization passes targeting C, C++, and Fortran don't tend to know, understand, or give a hoot about the constraints that need to be preserved in a GC-supporting optimization pass. Perhaps LLVM has done better, but the absence of any discussion of requirements along these lines that passes are expected to obey does make me wonder. Issue [3] is actually an example of many. More generally, there are a range of issues identified in David Chase's 1997 thesis *Garbage Collection and Other Optimizations*, and a subsequent refining paper jointly with Boehm, that the LLVM infrastructure simply doesn't address. Similarly, the kind of apprach suggested in his work with Detlefs *Garbage Collection and Local Variable Type-Precision and Liveness,* and it's later refinements, don't seem possible in the LLVM framework (I would love to be mistaken). > And, regardless of whether you use compiled stack maps or the shadow stack, > the actual collector -- the trickiest bit by far -- is still up to you. > Absolutely. And in the absence of a compiler that preserves the necessary information across phases, there is absolutely no point trying to deploy any of the good - or even moderately good - GC strategies. > High-performance garbage collectors are strongly tied to a language > implementation's object model and semantics. > This is not as true as people want to believe. It is true in the sense that there are significant design concerns in the layout and content of object headers in some GC systems. And there are certainly *ad hoc* design decisions one can make if one knows that, say, cons cells are unusually prominent in the data set. But the reality today is that there are no single-language address spaces, and consequently, an effective collector simply *can't* depend heavily on the high-level object model. We don't need collectors that are good at Java - or rather, we do, but not in a native-targeting compiler. What we need is the information from the compiler to let us collect successfully in mixed-langauge heaps. And yes, I know the compiler is only part of the problem. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
