Distinct closure types vs. known infotables for stack frames

[Simon Peyton Jones]

> 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. :)

I suspect it's all just happenstance.   Maybe @Ben Gamari
<bgamari at gmail.com> knows.

One you've had all responses, perhaps document your conclusions in a Note
somewhere, and point to it copiously.



On Tue, 27 Jun 2023 at 22:53, Alexis King <lexi.lambda at gmail.com> wrote:

> 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/20230628/382a2cb7/attachment.html>