[m-dev.] Help: Changes to memory zone allocation affecting my changes

[Thomas Charles CONWAY]

Warwick Harvey, you write:
> Firstly, in the original version, the heap pointer for the global heap was
> just another global variable, like the pointers to the various heap zones.
> I'm now wondering whether it would be more appropriate to have it as a
> virtual register (or whatever you call them), like the other heap pointers.
> If so, how does one go about setting this up?  I've had a look at
> mercury_regs.h et al., and I'm not game to touch anything without
> instructions.  :-)  If not, how would I set up "global" variable for this
> pointer for each thread (other than the one stored in the engine
> structure)?

See my earlier message.

> 
> Secondly, the MR_make_permanent() and similar calls worked by fiddling with
> the heap pointers and zone pointers, and then calling deep_copy() to copy
> the term from the normal heap to the "global" heap.  The heap pointer
> fiddling is still fine, but what is the approved way of obtaining the zone
> pointers for the thread?  This (I suspect) is just a case of obtaining a
> pointer to the correct engine structure, but what's the right way to do
> this?  Also, do I really need to fiddle the zone pointers for calling
> deep_copy, or will just exchanging the heap pointers do?  I suspect I might
> be able to get away with the latter, but that for safety's sake (e.g. a
> change in implementation, or for heap overflow checking) I'd better stick
> with the former.

In mercury_engine.h there is a macro MR_ENGINE(x) which expands to
the field x of the current MercuryEngine. For your purposes, you shouldn't
need to alter the zones at all. The problem may be locking.

> Thirdly, there still seems to be a few remnants of the old system floating
> around.  E.g. mercury_memory.c still declares the zone pointers, and a
> number of places refer to them if various "non-standard" options are being
> used (I include non-GC grades as "non-standard" here, just coz they always
> seem to give me more trouble ;-).  I provide a (possibly incomplete and
> possibly erroneous) list of stray references to heap_zone below:

Oops. Thanks.

Thomas
-- 
Thomas Conway <conway at cs.mu.oz.au>
Nail here [] for new monitor.  )O+