11.3 distributed memory management: Resource allocation

[Chris Harris]

On Tue, 6 Dec 1994, Mike Prince wrote:

> On Mon, 5 Dec 1994, Chris Harris wrote:
> 
> 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)

I'd again like to throw out the "nifty factor" of recursive stacks.  
Thus, a stack should be able to have N=infinity, but at the same time be 
able to have a sub-stack with an N of 1.

> An agent is a thread of execution, which has it's own local stacks

How do you plan to represent agents  Would they simply be an offset into 
a toolbox function, along with stacks, or would they store actual 
platform-independent code?  How would this differ for native toolboxes?

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

This seems too structured to me.  Unless these limits are enforced only 
be an easily-changable module, we're going to end up finding its too 
limiting one of these days.  What if we implimented this, and then 
decided that we needed some sort of storage for a parallel-processing 
agent?  How could we extend this?

I'd definitely like to hear more about parents and children.  At least 
for the original MOOSE project, object-oriented was one of the key goals, 
and I'm not hearing much about it here.  I know I'd like to see a 
"truely" (subjective word here) OO OS, rather than simply an object 
programming model, like NextStep....

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

Here's another thought I just got.  Instead of having one 
VCPU/stack/whatever low-level language, let's allow lots and lots of 
them.  Each tool, or whatever they're called, is then written for the 
most appropriate low-level language, weather it be stack-based, VCPU, 
list based, whatever, and an ID number would tell it which one to use.

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

You present some interesting arguments, but I would be inclined to allow 
more multiple types of data, so that only the most appropriate tool needs 
to be used.  I guess I need to hear more about how you plan to merge the 
stack model and objects....

> 
> Mike

One last question for you....  Can toolboxes/stacks/etc be spread across 
multiple machines, only partly loaded into memory, etc.?  It sounds like 
your toolbox model doesn't fare to well if you wanted to have two 
connected agents executing in parallel on two seperate machines.

-Chris