11.3 resource allocation

[Francois-Rene Rideau]

> We are working on the same problem from two different vantage points; Fare
> from the OO high end of constructors/destructors and inheritance, and I 
> from the hardware implementation side.
Yes, you're right.

> You want as much versatility, I want that balanced with good speed.
> My framework is meant to show HOW our system could work.  It is good to 
> talk OO theory, but please address the implementational side of things as 
> well.

> Let's see if we can agree on a few things right off the bat.

> Our OS is meant to exist in a very distributed environment.
> 	This is our GLOBAL layer.
> It is composed of everything out there. This exists, period.  Lets name it.
Completely Ok.


> Software will be distributed to users.
> 	I call these TOOLBOXES.
> Remember, this is not the programming side, but the distribution side.
That's difficult. users are programmers and the other way round.
So there may be packages distributed that include a lot of small sub-objects
available.

> I have the feeling Fare believes that once I get a TOOLBOX from vendor X, I 
> should be able to add functionality to it by inheriting its properties a 
> la OO programming.
Err, I like OO (it depends what you call OO), but I dislike inheritance.
I'd say that you combine existing objects to create new ones, more adapted to
what you need.


> Is this true?  If it is we either need access to the 
> source code, or our distribution format needs to be rich with information 
> about our a TOOLBOXES internal routine names, data structures, etc.  This 
> will slow re-compilation during migration of code to different 
> computers.  It will also make our distributions fat.  I am leery about 
> making such a compromise.
> The alternative, is to have TOOLBOXES be black-boxes of functionality 
> with multiple entry points and a versatile data-passing mechanism.
Free software will provide source, which allows best compilation and most
speed. Protected commercial software will use the latter method, so no
source is available; to provide efficiency anyway, commercial software
can provide fat binary versions for time-critical objects.



> Stacks provide us this versatile data-passing method; almost anything can 
> be handed in and given out.
Let's have high-level abstractions to represent communication; not low-level
implementation. Then, our standard libraries can map those abstractions
to stacks or anything actually available with best performance.



> Fare, please address how OO programming practices would influence 
> distribution format of code.  I.e does an application come in one big 
> package, or is it a collection of code fragments that can be farmed out?
It depends on what you call "application". Some software like "wordperfect"
wouldn't be just one toolbox in Tunes/Joy; basically, you'd have just an
object to manage some kind of thing between TeX and dvi; it would use
the standard User Interface for input/output, and would be integrated to
the rest of the system. Then, you could use "rich text" objects anywhere in
the system...

> What shall we call these code fragments?
toolboxes or objects, or whatever.

> If the code can be farmed out, how do we manage intra-code and code-data 
> dependencies in a distributed environment?
*That's* a big question, particularly if objects migrate (and they do, be
it only between permanent media and RAM).
It does merit a discussion of its own.

> Then, how can we 
> do subroutine calls/returns FAST?  I've gone on too long already.
In continuation-passing style, you have no stack, but call/return is just
a jump instruction; the destination should handle whatever is needed to
continue computation (which can be using a stack or not).

> 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.
We must codesign implementation and specification: designing one without the
other would result in an unadapted system.


> 	A DOMAIN is a useful way of corraling your resources.  Is there a 
> 		better way?
GLOBAL and LOCAL is ok. but as for DOMAIN, we must well understand that
there is an arbitrary recursive organization of domains, where the GLOBAL
one is the highest, and where LOCAL ones are the lowest, but where anything
may lie in-between...

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
MOOSE project member. OSL developper.                     |   |   /
Dreams about The Universal (Distributed) Database.       --- --- //
Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE   /|\ /|\ //
Phone: 033 1 42026735                                    /|\ /|\ /