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

Warwick Harvey wharvey at cs.monash.edu.au
Mon Jun 15 15:28:36 AEST 1998


Fergus writes:
> On 11-Jun-1998, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> > 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.
> 
> Well, it depends.  Is the global heap going to be
> 	(a) really global
> 	(b) per thread (i.e. one for each _Posix_ thread)
> 	(c) per Mercury engine
> 	(d) per Context (i.e. one for each Mercury thread)
> ?
> 
> I think it is unlikely to ever be worth putting the heap pointer for
> the global heap in a real machine register.  But if the answer is
> (b), (c), or (d) then just using a global variable isn't the right answer.

I agree that it is unlikely to be worth putting the heap pointer in a real 
machine register.  I am also intending to have a separate heap for each 
Mercury engine, as per the other heaps.  Now, from what I understand of the 
code, whenever an engine is swapped, certain values are copied back into the 
old engine structure, and then copied out of the new one (specifically, the 
main heap pointer MR_hp and the solutions heap pointer MR_sol_hp).  (At 
least, there are load_engine_regs() and save_engine_regs() macros that do 
this).

Now, in terms of status (at least from a HAL point of view :-), I'd put the 
global heap about on par with the solutions heap, but still well behind the 
main heap (feel free to correct me if you think I'm wrong on this point).  
This suggests to me that I should define a MR_global_hp similar to 
MR_sol_hp, along the lines of

#define MR_global_hp  LVALUE_CAST(Word *, count_usage(MR_GLOBAL_HP_RN, 
mr(41)))

(or whatever).  Is this inappropriate?  If it is not inappropriate, are 
there other implications?  Is there any documentation describing what else I 
might have to do if I want to do this?  I'm prepared to have a stab at just 
doing "the obvious thing", but if there are some not-so-obvious pitfalls to 
be avoided, some guidance would be appreciated.

And if it's not the way to go, should I just refer to MR_ENGINE(e_global_hp) 
whenever I want to access it?  (Or rather, define MR_global_hp to be this).

Finally, I noticed something which looks suspicious in mercury_regorder.h.  
I don't know whether it's a bug or not.

#define MR_min_hp_rec   LVALUE_CAST(Word *, count_usage(MR_MIN_HP_REC, 
mr(38)))
#define MR_min_sol_hp_rec       LVALUE_CAST(Word *,     \
                        count_usage(MR_MIN_HP_REC, mr39))

Note both of these refer to MR_MIN_HP_REC; I would have expected the latter 
to be MR_MIN_SOL_HP_REC.  Also, I expected mr39 to be mr(39).  (Same goes 
for the other half of the thread safe #if/#else).

Warwick




More information about the developers mailing list