logical vs physical spaces (was Re: Versioning and persistence)

[Francois-Rene Rideau]

[Beware: cross posted from LispOS to LispOS and Tunes;
mind where you want your follow-up to be read]

>>>: Chris Bitmead on LispOS
>>: Fare Rideau on LispOS
>: Pierpaolo Bernardi on LispOS

>>> Most people on this mailing list want to have a single address space
>>> for all users.
>>>
>> I think that specifying such an idea would be basically *wrong*.
>
> I thing this view is basically wrong.  For reason which have been
> amply discussed in this list.
>
Hum, are you agreeing with me or disagreeing? I'm not sure what you mean.

>> There should be one *logical object space*,
>> whose implementation is not specified.
>
> Care to elaborate? [...]
>
Of course, see below.

> And, to clear any possible ambiguities, can you exactly define what do
> _you_ mean by 'address space' ?
>
Wise precaution.

To me an address space is a *low-level view* on object locations
that provides some kind of "flat" memory model,
with a uniform pointer/ID type that can be uniformly used and exchanged
within the space.

   For instance, what a Unix process gives you is a 32-bit address space
(well, ok, might also be 16 or 64bit depending on the architecture).
Two unix processes do not share address space (unless using shared memory),
in that you can seamlessly interchange pointers from one to the other.
Unless you have a DSM, two different hosts on the net do not share the
same *address* space. Some DSMs (Distributed Shared Memory)
you a transparent 64-bit address space even on 32-bit architectures
(Texas, Grasshopper?).

   As another example of an address space, I'll give the WWW,
as URLs are also some kind of pointers on web objects:
you can exchange them, and use them uniformly to access the same data.
The WWW has lots of badly behaved characteristics (unreliability,
slowness, high redundancy but low availability or error-correction,
lack of clean structured semantics, etc); still it is a one address space.

   Are you satisfied with the definition?


An *Object* space is not the same as an *address* space.
In an object space, you don't know or care
how the objects point to each other; they just seamlessly interact,
according to *high-level semantics*.
You don't look at an object's address, and peek at its contents;
you have apply operators on objects, you group them into structure
that you later destructure, you evaluate generic functions on them,
you move or copy them, you prove them correct or incorrect,
you publish them worldwide, or send them privately to your girlfriend, etc.
In any case, you just DON'T GIVE A DAMN how it's done internally,
as long as its done *correctly*, and *in reasonable times*.

   The underlying implementation could use
one global DSM of an address space or several address spaces,
no one fucking ain't care -- these are only gory technical details.
Well, we technicians care, and for obvious trust reasons,
one global DSM just ain't possible. So,
local objects would exchange local pointers,
and use proxies to access remote objects.
When objects are moved accross the net, they adapt to their
new environment, and are recompiled with a new concept of
what's local and what's remote.
All that without the user having to mind or care,
without having his important program suddenly abort
with a weird message claiming that there be some kind
of bizarre incompatibility between things he doesn't understand.

   Of course the user's not HAVING TO know
does *not* imply his not BEING ABLE TO know.
For performance as well as security, the user/programmer *must* be able to
control what goes in and out of the objects he owns.
The difference is that the system will implicitly manage all the
marshalling, transcoding, checksuming, signing, negociating, transactioning,
synchronizing, invalidating, serializing, chekpointing, rolling-back,
inlining, recompiling, garbage collecting, etc,
that are necessary to move objects between address spaces.
The user-programmer controls the semantics up to whatever point he wants,
and the system does the rest in whatever correct way is the most efficient
that can be found automatically.

   And because one can never say in advance what the other people's
address space will be like, because you will always want to
integrate another one's system into your world for seamless communication,
it is just impossible to limit the system to one address space,
or even to a statically known number of address space and/or address space
protocols. Hence, the object space must must be reflectively extensible.
Yet another reason why an OS must be built upon a reflective kernel.
The initial implementation starts with one address space,
and uses reflection to provide inter-address-space unification.


So, to conclude, One Object Space, YES (unified high-level semantics).
One Address Space, NO (it's just not even possible).

  The specs for the OS should be in high-level terms, and only talk about
the object space, and about the attributes of ownership and trust
attached to objects.
The implementor is free to use whatever means he thinks adequate,
as long as the high-level specs are correctly implemented.
He might use paging hardware when there is;
obviously, when there ain't any, he won't use it.
Similarly, he may use 64-bit flat pointers,
but on 8/16/18/20/32/36/128 bit architectures (single CPU or maspar),
that might not be his first choice.


Regards,

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"