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

[Peter Wang]

On Sun, 01 Nov 2026 00:42:56 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Sun, 1 Nov 2026 00:31:10 +1100, Julien Fischer <jfischer at opturion.com> wrote:
> 
> > 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.
> 
> Yes, it does. We should probably do something about that.
> 
> I also thought about this when I looked at the code that unprotected the redzone
> when a zone was being freed. When we next take that zone off the freelist,
> and start using it again, we would probably want to set up a redzone again.
> In the presence of soft redzones, the new redzone may be of a different size,
> but if we are using hard redzones only, it will always be the same size. That means
> that both syscalls in the unprotect/reprotect pair are wasted. It would have been better
> if zones on the freelist simply recorded what their protection status was, and
> when reusing a zone from there, we left the existing protection in place if it matches
> the new need.

MR_create_or_reuse_zone uses the recorded redzone size to avoid
unprotecting/reprotecting the redzone unnecessarily.

> 
> Of course, I don't think we ever really reuse memory zones in non-parallel,
> non-segment grades, so the point is moot for them.
> 
> > > 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.
> 
> I don't think they *ever* worked. I don't think they were ever *intended* to work,
> in that noone ever worked on them seriously.

> > > 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.
> 
> I notice you didn't comment on this part. Do you think soft redzones are needed?
> I don't.
> 

With Boehm GC, it might be possible to set a custom mark procedure to
scan only the part of the memory zone up to the soft redzone mark.
I haven't tried it.

If we were using own own GC (perhaps agc if it worked), another possible
use of soft redzones could be to reserve virtual address space for a
memory zone without committing physical memory for the entire region.
When a page fault occurs within the soft redzone, then we could map
additional physical memory to the memory zone. This probably would have
been more relevant when a few megabytes was a lot of memory.

In short, I think soft redzones are not needed now.

> > > > > 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
> 
> That works for me. However, whatever terminology we pick, we have to
> use it *consistently*.

Guard page(s) works for me.

Since Julien started cleaning up some of the related code, I'll leave
any further changes to him.

Peter