Distinct closure types vs. known infotables for stack frames

[Ben Gamari]

Alexis King <lexi.lambda at gmail.com> writes:

> Hello all,
>
> I am tinkering with the RTS again while trying to fix #23513
> <https://gitlab.haskell.org/ghc/ghc/-/issues/23513>, and every time I touch
> the exceptions/continuations code, I find myself waffling about whether to
> introduce more closure types. I’d like to get a second opinion so I can
> stop changing my mind!
>
Indeed I have had similar questions in the past. In principle, I personally
think that using closure types to distinguish special info tables is
conceptually cleaner.

However, the trouble is that it is also, at least in principle, more
costly. Specifically, branching on closure type requires that we examine
the info table, which may incur a cache/TLB miss. While one would hope
and expect that "common" info tables are already in a nearby cache, it's
ultimately very easy to side-step this cost entirely by simply branching
on the info table pointer.

This tension has lead me to waffle in similar ways as you report. On the
other hand, it seems hard to avoid given the tricky trade-offs involved.

My (rather loose) policy when working on the RTS has typically been:

 * When introducing a new closure/stack-frame info table that differs
   markedly from any that already exist, give it a new closure type.

 * When matching on the info table, follow the example of surrounding
   code when deciding whether to match on the closure type or info table
   pointer

 * If there is no appropriate nearby similar logic to follow, use my gut
   to assess how hot the check will be and unless it is quite warm, use
   the closure type.

However, I'll admit that this policy likely only contributes to the
inconsistency. Perhaps you have some clever idea on how things could be
improved?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230628/6da0eb17/attachment.sig>