a few thoughts

[Jonathan S. Shapiro]

> Simple directories don't need processes to hold them.  They can be
> implemented as nodes holding a key to a node containing keys and a key
> to a page containing their names and traversed by library routines.  As
> long as you can do anything with a start key you can do with a page or
> node key, the library can be fairly oblivious to directories
> implemented in other ways.

There is no protection-motivated reason for a separate process, but for
purposes of fault isolation and freedom to change implementation there are
reasons to use a separate process. The implementation you describe is
marginally more space efficient than the obvious directory implementation,
but in practice is probably not significantly faster. Also, it precludes
code sharing among the directory implementations unless we use shared
libraries. Shared libraries in the absence of encapsulation raise a bunch of
other security concerns that we really need to work through.

> I'm not sure that downcasting in Java is a design flaw; in particular,
> it makes possible the implementation of generic and heterogeneous
> container classes, such as the directories being discussed.

That's what templates (aka generics) are for. What the Java approach really
makes possible is the implementation of heterogeneous lists. Either the
objects on the list truly share a common interface, in which case you can
build something of the form [list of <things that implement interface X>],
or they don't, in which case the software is misdesigned.

If two codes are exchanging Walnuts through a vector, they should use a
Vector of Walnuts, not a Vector of Objects.

In any case, my objection was not to downcasting inherently. It was to the
fact that downcasting is implicitly a feature of all interfaces. I have no
objection to a keyword on the interface that says "downcast from interface
to class is permitted". My objection is that there are places where for
security reasons such a downcast should *not* be permitted because the type
thinning represented by the interface must be strongly enforced. Therefore,
there needs to be some form of interface-like abstraction in which the
downcast is disallowed. In Java, this requires the introduction of proxy
objects. Proxy objects in turn break representation identity.

> The L4 HotOS 97 paper "Achieved IPC Performance" claims <1uS IPCs on
> Pentium-166s.  Is this bogus? If not, why is EROS fast-path IPC pipe
> latency an order of magnitude slower at 18uS?  (I know it involves
> several IPCs, but ten?)

Yep. Ten is actually about right. Recall that by "pipe" here we mean the
UNIX-style entity. A pipe is a channel providing a bounded-size buffer, and
that it's protocol must therefore do more IPCs and must perform a marginal
data copy. Collectively, these account for the pipe bandwidth.

The current EROS IPC implementation is buggered, and I didn't have time to
fix it while under the time constraints that IBM imposed for what I could
actually release. It won't gain back all of the difference you noticed, but
it will recover a fair bit of it.


shap