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

[Fergus Henderson]

On 15-Jun-1998, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> Fergus writes:
> > 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.

OK, that avoids the need for locking.
You just need to put data in the engine structure.

> 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).

These macros save/restore those values which are (a) engine-specific
and (b) stored in Mercury virtual registers, in case those virtual
registers are mapped to real registers.

> 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)))

The solutions heap pointer is mapped to a Mercury virtual register.
This has some advantages (we can profile its usage, and it could get
mapped to a real register) but it does require a little bit more
infrastructure.  If there's no prospect of a particular piece of
state becoming a real register, there's not much advantage in making
it a virtual register.  On the other hand, there's not that much
disadvantage either.

I don't mind whether you make MR_global_hp a virtual register or not.

> Is there any documentation describing what else I 
> might have to do if I want to do this?

No.

> 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).

Yep.

> 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).

These look like bugs to me.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.