11.3 distributed memory management: Resource allocation

[Mike Prince]

On Mon, 5 Dec 1994, Chris Harris wrote:

> I'm having a little trouble understanding the difference between stacks, 
> tools, and agents.  If I'm seeing things correctly, a tool is like a 
> function in your generic HLL, the toolbox-wide stack(s) are like global 
> variables, and agents correspond to low-level objects.  Is this far off 
> from what you're thinking of?

A tool holds functions
A toolbox-wide stack holds your data (global variables, accessable to all 
	agents, within that toolbox)
	BTW, for synchronization, I'm thinking of applying blocking semaphores
		in order to access stacks, so only N agents can be using
		a stack at a time (N=1 usually)
An agent is a thread of execution, which has it's own local stacks

> Also, how much of a difference is there between a tool/agent and a 
> stack?  Would it make sence to have agents and tools simply be stacks 
> formatted in a way that the OS can understand?  It would certainly make 
> it easier for applications that need to generate on-the-fly code.  
> (Something that ought to be supported, methinks.)

The OS storage primitive is a segment of memory.  The handle contains 
fields which link that segment to its parents, children, etc (more about 
this later).  A segment can be a toolbox, tool (either virtual machine 
code or binary), stack, agent_state (for storing thread information), 
jump_list ( for redirecting exectution within a toolbox), or a link_list 
(for redirecting execution outside a toolbox).

You're absolutely right about generating on the fly code.  A simple 
instruction, Codify, will take virtual machine code in a stack, and add 
it as a tool to the current tool box, updating the jump_list.  A tools 
entry points are listed in the jump list.  Once all the entry points of 
an older tool have been hooked by newer tools a garbage collector can 
remove the old tool.

> Sounds good to me....  We'll obviously need to make concessions for 
> local-only toolboxes (such as the "kernel", or whatever the joy-correct 
> word is for extremely low-level stuff), as well as rudundent toolboxes, 
> for backup purposes.

Toolboxes and agents can be bounded to Local, Domain, or Global (not 
bounded at all).  I still don't have a good solution for redundancy.  It 
can come in two flavors, or a combination thereof;

Each Local will periodically create messages to itself of all its 
toolboxes and store it in a backup "place" (my test kernel just dumps all 
the messages into a directory called bak).  If a system fails, it can 
restart from the last backup, albeit with a lot of syncronization 
problems with other systems.

Another version is to have a lot of copies of commonly used software 
hanging around on nearby systems.  Lose your copy, just recopy it from 
someone else.  Worst case, get one from the source, over the net. 

> I'm not quite certain why everyone is so pro-stack around here.  Sure 
> they're great for allocating/deallocating vars in procedure-based langs 
> like C, but do they really fit the object-oriented model ok?  It would 
> seem that an environment where objects are flying all over, changing 
> frequently, it would be better to use something similar to the heap 
> system used in MacOS.

> You seem to be saying that these stacks could support random access, but 
> if they do, it would seem to defeat the purpose....  I think I'm 
> also misunderstanding how stacks could really help out GC much.  

> What if we wanted axe the item in the middle of the stack?  The OS 
> can't reclaim that space.  Seems it could only re-claim stack 
> memory if you removed the top of bottom element of the stack, which 
> doesn't provide much in the way of flexibility.

Your right about losing the middle, but see below..

Stacks come from the heap.  To do a normal alloc() just create a stack 
big enough to hold your data, and de-allocate it when done.  Normal OS 
will do the GC for you.

The advantage of stacks over using a heap is that GC is easier and data 
being accessed tends to be close together.  One of the failings (begin 
flaming) is that OO languages tend to spread their data all over the 
place, spending a lot of time allocating and de-allocating, and GC.  They 
also have the potential of giving the CPU cache a really hard time if the 
data is too spread out.  A stack is a very good way of minimizing these 
problems.  Although I do recognize that they aren't the ultimate 
solution, which is why stacks can be viewed as a random access object as 
well to appease the purely OO crowd.  The winning solution will be the 
one that runs the fastest in the end, and I'm betting a more 
stack-centric programming method will.

Mike