Hello all,

I am tinkering with the RTS again while trying to fix #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!

Currently, we have distinct closure types for certain special stack frames, like CATCH_FRAME, ATOMICALLY_FRAME, and UNDERFLOW_FRAME. However, there are other special stack frames that don’t get their own closure types: there is no MASK_ASYNC_EXCEPTIONS_FRAME or PROMPT_FRAME. Instead, when code needs to recognize these frames on the stack, it just looks for a known infotable pointer. That is, instead of writing

if (frame->header.info->i.type == PROMPT_FRAME) { ... }

we write

if (*frame == &stg_prompt_frame_info) { ... }

which works out because there’s only one info table that’s used for all prompt frames.

There are a handful of stack frames that are recognized in this way by some part of the RTS, but the criteria used to determine which frames get their own types and which don’t is not particularly clear. For some frames, like UPDATE_FRAME, the closure type is necessary because it is shared between several infotables. But other types, like CATCH_FRAME and UNDERFLOW_FRAME, are only ever used by precisely one infotable.

I think one can make the following arguments for/against using separate closure types for these stack frames:

Does anyone have any opinions about this? I’m personally okay with the status quo, but the inconsistency makes me constantly second-guess whether someone else might feel strongly that I ought to be doing things the other way!

Thanks,
Alexis