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

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

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

> 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. O

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

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 pe

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

Thanks for a clear writeup, Alexis. My instinct is to do it all with closure types, not pointer comparison. - > > Con: Adding more closure types unnecessarily pollutes code that branches > on closure types, like the garbage collector. > - > > Con: Adding more closure types unnecessarily pollutes c

Distinct closure types vs. known infotables for stack frames

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 sto