Alexis King
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