The shadow stack is a piece of a GC implementation which LLVM provides for clients to use or ignore as they wish. Nothing says you have to use the shadow stack, and if you do use it, it's very easy to subsequently transition to using stack maps. As the quote there says, using a shadow stack is the easiest way to get started with GC 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. But LLVM includes sample code for stack map compilation, so the difference in difficulty for that bit is quite low.
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. Which is as it should be. High-performance garbage collectors are strongly tied to a language implementation's object model and semantics. You might get decent performance from another language's GC, but you'll never get great performance, especially on pause times. And especially for BitC, it seems like pause times are much more critical than raw throughput... On Thu, Apr 7, 2011 at 7:51 PM, Ben Kloosterman <[email protected]> wrote: > http://llvm.org/docs/GarbageCollection.html > > > > “Unlike many GC algorithms which rely on a cooperative code generator to > compile stack maps, this algorithm carefully maintains a linked list of > stack roots > [Henderson2002<http://llvm.org/docs/GarbageCollection.html#henderson02>]. > This so-called "shadow stack" mirrors the machine stack. Maintaining this > data structure is slower than using a stack map compiled into the executable > as constant data, but has a significant portability advantage because it > requires no special support from the target code generator, and does not > require tricky platform-specific code to crawl the machine stack. > > The tradeoff for this simplicity and portability is: > > - High overhead per function call. > - Not thread-safe. > > Still, it's an easy way to get started. After your compiler and runtime are > up and running, writing a > plugin<http://llvm.org/docs/GarbageCollection.html#plugin> will > allow you to take advantage of more advanced GC > features<http://llvm.org/docs/GarbageCollection.html#collector-algos> of > LLVM in order to improve performance.” > > Has the shadow stack changed ? > > > > Basically as documented , the default GC architecture in LLVM allows you to > get up and running quick ( which is great for research ) and works with most > languages but there is a significant price in performance. The faster > languages probably have written their own GC extensions or even GC. > > > > The CLR on the other hand gives a fast and mature concurrent GC ( but with > large GC pauses) the main issue is the manual pinning that needs to be > done for references from static data.. > > > > Ben > > > > > > > > > > *From:* [email protected] [mailto:[email protected]] > *On Behalf Of *Ben Karel > *Sent:* Thursday, April 07, 2011 11:00 PM > > *To:* Discussions about the BitC language > *Subject:* Re: [bitc-dev] Request for advice on choice of a GSoC project > > > > On Mon, Apr 4, 2011 at 8:42 AM, Ben Kloosterman <[email protected]> > wrote: > > I will second that the whole shadow stack is a bad approach from the start > , it needs a redesign. Eg apps can emit GC code snippets , while not too > difficult to do it’s a architectural change which requires more from > application and hence some politics.. > > > > Wait, who said anything about a shadow stack? > > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
