11.3 resource allocation

[Mike Prince]

On Tue, 6 Dec 1994, Chris Harris wrote:
> If we are to have a OO OS, as I am all for, this ability you do not seem 
> to appriciate is VERY important.  If we do not let the users/developers 
> modify their system as much as they feel they need, we really haven't 
> progressed much farther than unix....

> > Stacks provide us this versatile data-passing method; almost anything can 
> > be handed in and given out.
> 
> Okay, but I also think we should be able to pass lists, objects, dna 
> samples from a local rubber puppy, whatever.  If these can be captured 
> inside a stack, without making it too complicated, this might still work.

Yes they can, I'll go into that more later...

> > The multiple entry points coupled with a tool boxes ability to 
> > advertise entry points and their capabilities.
> 
> Sounds good, but the user should be able to modify them, if they suddenly 
> get a brilliant idea as to how this object could better fit into their 
> hiarchy.

It's up to the toolbox.  It may provide a routine to integrate new code 
or it may not.  Remember you're in a distributed environment now.  An 
agent could be getting into the toolbox from somewhere else and doing 
something you might not want.  This is a big problem of how to control it.
If we leave it up to the toolbox, we're building in versatility.

> > Finally, if we break code up into discrete toolboxes we can manage 
> > migration more easily.
> 
> True, but do we necesarily want generic migration?  Seems to me we'd want 
> support for partial migration, anything to get the maximum efficiency out 
> of the stuff.  Recursive representations might help us more easily move 
> sub-sub-sub agents around the place, if we so desire....

Just as in real processors, there are no sub-sub time-slices.  Each agent 
is simply a time slice, to execute code somewhere.  Toolboxes shoould be 
small enough to provide a fine enough grain of migration.  I'm hoping to 
keep toolboxes under a couple K of code and data, and maybe a lot smaller.

> > These are implementational issues that must be addressed.  We cannot look 
> > at the ideal pure OO language.  We are looking at an *operating system*.
> > Everything must work together; programmers, hardware, users, etc.
> 
> Quite true, but this doesn't prevent us from having fairly low-level OO 
> stuff.  The flip side of most of the arguments you're present here (based 
> on speed) is how the USERS percieve speed.  Sure, objects might not be 
> the most efficient way to run long computations, but something can surely 
> be said for the drastic reduction in development time that would take 
> place, and how much more productive the users might feel.  A happy user 
> working a bit slower is better than an unhappy user working at full speed....

I'm all for OO programming as an aid to faster development of 
applications.  But I want to balance as best as possible the benefits of 
OO programming, OO operating systems, and speed.

An OO program, when it's running looks just like C to the CPU (or 
BASIC for that matter).  So down low, we'll do what's fastest to run what 
you've written up higher using OO programming.

So....You tell me what will be handed down to the executive, and then we 
can optimize that to give you the fastest execution possible.

Mike