[m-dev.] Reorganization of mercury_memory.c
Tyson Dowd
trd at cs.mu.OZ.AU
Tue Apr 28 10:05:34 AEST 1998
On 27-Apr-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 27-Apr-1998, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > I need to modify mercury_memory.c to implement accurate GC, but it's a
> > bit of a mess (so much conditional compilation) so I'm going to
> > reorganize it into:
> > mercury_memory_zones.{c,h}
> > The MemoryZone data type and functions
> > mercury_memory_handlers.{c,h}
> > The signal handlers for seg faults, and redzones.
> > mercury_memory.{c,h}
> > The leftovers.
>
> That looks OK, I guess.
> What's in the leftovers?
> I suppose that would be the one that knows about the particular
> zones needed by the Mercury runtime, with the others all being
> zone independent?
Mostly, and some debugging code, and a few thinks like checked_malloc.
> > For example, have
> > MR_CAN_GET_PC_AT_SIGNAL
> > rather than HAVE_MPROTECT && (HAVE_SIGINFO || PC_ACCESS).
>
> In this particular case, I think the example you chose is
> perhaps misnamed: something named CAN_GET_PC_AT_SIGNAL
> should not depend on HAVE_MPROTECT, should it?
> Perhaps you want CAN_GET_PC_AT_SIGNAL to be true iff
> HAVE_SIGINFO || PC_ACCESS, with say CHECK_OVERFLOW_VIA_MPROTECT
> defined to be true iff HAVE_MPROTECT and CAN_GET_PC_AT_SIGNAL
> are both defined.
Yep, that sounds better. I haven't worked out the particulars at
the moment.
--
Tyson Dowd # So I asked Sarah: what's the serial number on
# your computer? She replied:
trd at cs.mu.oz.au # A-C-2-4-0-V-/-5-0-H-Z
http://www.cs.mu.oz.au/~trd #
More information about the developers
mailing list