[m-rev.] for review: Clarify some code relating to redzones.

[Julien Fischer]

On Sun, 1 Nov 2026 at 00:12, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
>
> On Sun, 1 Nov 2026 00:03:34 +1100, Julien Fischer <jfischer at opturion.com> wrote:
>
> > Hi Zoltan,
> >
> > On Sat, 31 Oct 2026 at 20:47, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:

>
> > > - The soft redzone is the rest of the redzone. It starts out with no access
> > >   being permitted (or as close to it as mprotect/equivalents can get),
> > >   but we undo this protection on access.
> > >
> > > - The purpose of the hard redzone is definitely to guarantee that we catch
> > >   about-to-happen overflows.
> >
> > This suggests that for some uses of memory zones we don't need hard redzones.
> > (The zones used for stack and trail segments are the obvious examples.)
>
> Exactly. I don't think this interaction was thought through when we introduced
> segments.

It does raise the question of whether we are incurring a system call for
every stack or trail segment.

> > > This requires the hard rezone to be at least as big
> > >  as the largest stack frame.
> > >
> > > - The possible purposes of the soft redzone are: (a) keeping track of how much
> > >   of a memory zone is actually used, both for plain curiosity and to inform
> > >   decisions about how big we should make memory zones, and (b) to help
> > >   Boehm gc do its job faster, by ... (fill in the blank, because I don't know
> > >   the mechanism by which this would work).
> > >   I don't think (a) is relevant anymore, because we can get the same info
> > >   in a more useful manner using stack segments. I have no idea whether
> > >   (b) is still relevant. If it is not, then we can stop using soft redzones,
> > >   though keeping its code around wouldn't hurt, *provided* that the code
> > >   is *documented* as being unused.
> >
> > I don't think (b) is a thing.  MR_default_handler() is the only function that
> > handles access in redzones.  The only interaction it has with a garbage
> > collector is in low-level agc grades, where it calls MR_schedule_agc().
> > (Presumably, that only really matters when the zone in question is a heap
> > zone.)
>
> And also presumably, it only matters if agc works in LLDS grades,
> which I do not remember ever happening. Even in MLDS grades,
> agc worked only for (subjectively) five minutes.

LLDS agc grades didn't compile the last time I looked.

> That is an argument for soft redzones not being needed, and for documenting
> them as not being needed. We may still want to keep the trivial amount of code
> supporting them, but if we do, we should add comments saying (a) what functionality
> they are intended to support, and (b) that there is nothing to support just yet.
>
> > > Do you guys agree?
> >
> > In principle, sure. I would also offer the following observation:  using names
> > like  "redzone" and "hardzone" inside something called a "memory zone" is
> > fairly confusing.
>
> What terminology would you suggest instead?

I was trying to think of something.

  soft guard pages == soft redzone
  hard guard page == hard redzone

?

Julien.