An overhaul of the SRT representation
Concern Raisedeb8e692cab79

Authored by simonmar on Sep 26 2016, 6:07 AM.


An overhaul of the SRT representation


  • Previously we would hvae a single big table of pointers per module, with a set of bitmaps to reference entries within it. The new representation is identical to a static constructor, which is much simpler for the GC to traverse, and we get to remove the complicated bitmap-traversal code from the GC.
  • Rewrite all the code to generate SRTs in CmmBuildInfoTables, and document it much better (see Note [SRTs]). This has been something I've wanted to do since we moved to the new code generator, I finally had the opportunity to finish it while on a transatlantic flight recently :)

There are a series of 4 diffs:

  1. D4632 (this one), which does the bulk of the changes
  1. D4633 which adds support for smaller CmmLabelDiffOff constants
  1. D4634 which takes advantage of D4632 and D4633 to save a word in info tables that have an SRT on x86_64. This is where most of the binary size improvement comes from.
  1. D4637 which makes a further optimisation to merge some SRTs with static FUN closures. This adds some complexity and the benefits are fairly modest, so it's not clear yet whether we should do this.

Results (after (3), on x86_64)

  • GHC itself (staticaly linked) is 5.2% smaller
  • -1.7% binary sizes in nofib, -2.9% module sizes. Full nofib results: P176
  • I measured the overhead of traversing all the static objects in a major GC in GHC itself by doing replicateM_ 1000 performGC as the first thing in Main.main. The new version was 5-10% faster, but the results did vary quite a bit.
  • I'm not sure if there's a compile-time difference, the results are too unreliable.

Test Plan: validate

Reviewers: bgamari, michalt, niteria, simonpj, erikd, osa1

Subscribers: thomie, carter

Differential Revision: