[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