11.3 distributed memory management: Resource allocation

[Chris Harris]

On Mon, 5 Dec 1994, Mike Prince wrote:

<snip>

> 			TOOLBOX (for lack of better name, maybe a MODULE)
> 				TOOLS (our code)
> 				STACKS (our data, may be used as stacks or
> 					random access data, global to TOOLBOX)
> 				AGENTS (our execution primitive)
> 					STACKS (data only visible to owner
> 						agent)

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?

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

> Now on to the details of resource allocation.  Our heavy resource 
> allocation would be the movement of TOOLBOXES.  This would require 
> rounding up all their data, code, and resident agents, shipping them off 
> and recompiling them.  This should be avoided, but (my gut feeling), 
> would not be as computationally expensive as many think, as long as we 
> standardize our data format and have a low level language that quickly 
> compiles (almost a one-one macro-like translation is possible).  We could 
> also encourage the creation of "small" toolboxes (in Toas, if my memory 
> serves me, some are only a few hundred bytes).

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.

> The "light" resource allocation is for memory requests for STACKS.  If we 
> used a stack-based language, our stacks could grow and shrink on their 
> own.  When bounds are hit, the OS could automatically expand the STACK, 
> or if not possible, ship off the TOOLBOX to a LOCAL that could.  Also, 
> when one stack needs to get bigger, the OS could scan the stacks for 
> those with lots of "head rom" and shrink them up.  This way the OS would 
> be given the bulk of GC responsibilty.  Remember, though that we should 
> seperate mechanism from policy.  The OS provides the mechanism for many 
> of these things, but external TOOLBOXES would determine who goes where with 
> what.  This OS should be highly modular.
>
> One last note, just because I use the word stacks (distasteful to some) 
> doesn't mean they have to be used that way, you can also access them 
> randomly, provided you stay under the stack pointer.  However, if you 
> start to create holes in your stack, that makes GC a little harder.  I've 
> also opened the possibility of having multiple stacks (a little harder on 
> the OS and we take a hit for not having our data be nice and be close 
> to each other (poor cache!) but for those who want very dynamic storage, 
> we'd have it.

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.  (For those of you not familiar with macs, you can 
allocate objects in a heap, and then get a handle (pointer to a pointer) 
to the data.  The OS then moves stuff around as needed, and the handle 
stays valid.  The only problem you run into is if you want to dereference 
the handle to a single pointer, in which case you need to first lock the 
data.  Otherwise, it works pretty well.)  Apple obviously hasn't done the 
best job with it, but in an environment where stuff isn't compiled really 
until run-time, you could have the OS get around its own pointer problems.

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.

Whichever way we do go, stacks, heaps, or whatever, I would hope that it
would be somewhat recursive, so we could have stacks within stacks, or heaps
within heaps.

Any thoughts?