Distinct closure types vs. known infotables for stack frames

[Alexis King]

On Tue, Jun 27, 2023 at 4:13 AM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> In short, why are the design considerations for stack frames different to
> heap objects?  I think of a stack frame simply as a heap object that
> happens to be allocated on the stack
>

I agree with this perspective—I think it is generally an accurate one.
Indeed, I think it may very well be true that what I’ve described largely
applies to heap objects as well as stack frames, and working on
continuations just means I’ve much more time thinking about stacks. Perhaps
if I were working on the garbage collector I would be asking the same
question about heap objects.

For example, we have MVAR_CLEAN and MVAR_DIRTY, but each of those types is
only used by one statically-allocated infotable, as far as I can tell. In
some parts of the code, we check that the closure type is MVAR_CLEAN or
MVAR_DIRTY, but in other places, we check whether the infotable is
stg_MVAR_CLEAN_info or stg_MVAR_DIRTY_info. Meanwhile, we have both
stg_TVAR_CLEAN_info and stg_TVAR_DIRTY_info, but they share the same TVAR
closure type!

The decisions here seem fairly arbitrary. But perhaps there is some method
to the madness, or perhaps someone prefers one approach over the others, in
which case I would like to hear it! And if not, well, at least I’ll know. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230627/e926e182/attachment.html>