Re: 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
 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  wrote:

> On Tue, Jun 27, 2023 at 4:13 AM Simon Peyton Jones <
> simon.peytonjo...@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. :)
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Distinct closure types vs. known infotables for stack frames

[Ben Gamari]

Alexis King  writes:

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


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs