Distinct closure types vs. known infotables for stack frames

[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!

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:

   -

   Pro: It’s helpful to have separate types for particularly special frames
   like UNDERFLOW_FRAME because it makes it easier to remember which
   special cases to handle when walking the stack.
   -

   Pro: Branching on stack frame closure types using switch is easier to
   read than comparing infotable pointers.
   -

   Con: Adding more closure types unnecessarily pollutes code that branches
   on closure types, like the garbage collector.
   -

   Con: Using special closure types for these frames might make it seem
   like they have some special layout when in fact they are just ordinary
   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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230626/8564dc9f/attachment.html>