release 0.0.0.20 and thoughts
Thu, 17 Aug 1995 08:31:09 -0400
> But isolation doesn't cost that much (on hardware that supports
> virtual memory) because EVERYTHING goes through virtual memory.
> QNX supports virtual memory but doesn't swap (i.e. if you have
> 16M RAM in a QNX system, then you have 16M Virtual RAM - it
> doesn't swap out to disk).
From my point of view, it is. If you force virtual memory on
everything, many things will have trouble. If you only provide
virtual memory as a service to things that need it, nothing will
break. (Simplified case. Murphy's law may apply otherwise in some
Who defines need? The language designer? The code designer? The
code implmementor? The machine owner? The system guru? The end
user? One what criteria should this choice be made?
For that matter, what is meant by "virtual memory"? In my eyes,
virtual memory that isn't backed by disk space is just a marketing
More to the point, if we're going to be implementing persistent
objects, we're going to have to be implementing something more
sophisticated than virtual memory (e.g. something analogous to mmapped
files in unix). In this case, we're going to have to be managing a
very large address space -- far larger than the usual space addressed
by virtual memory.
But -- and this one is crucial folks -- we can not expect to get
somewhere if we try and argue that we need/don't-need some arbitrary
implementation technique before we've clearly defined what that
technique is, and what aspect of our goals it attempts to address.
Most of the specifications I've seen to date are very loose, and
subject to a lot of interpretation -- yet extensive and verbose.
I would say that we've been trying to define our goals and policies
for managing critical resources (memory space, processor time), that
we've not defined our goals adequately, and that we're arguing
technique as much as we're arguing vision.
Which is not to say that we don't have vision -- more that the visions
I'm seeing diverge rather heavily.