[cap-talk] "Same" key

Mark S. Miller markm at cs.jhu.edu
Tue Feb 6 20:39:14 CST 2007

David Hopwood wrote:
> "Communities", please, not camps. This isn't a battle, and many people
> consider themselves to be members of both communities.

Yes, thanks. Certainly.

> I'm afraid I don't have much time for anyone who tries to understand a
> concept in terms of just one implementation approach. (In the case of
> dynamic method dispatch, there are at least three approaches, of which
> v-tables are a special case of one [*].)

First, Bill himself understands all these concepts quite well. He's one of the 
architects of KeyKOS and has made substantial contributions to E. What he's 
trying to help us figure out is why various folks, such as Shap & I for 
example, have such a persistent difference in perspective about how to 
describe a common semantics. If you don't have time for Bill's approach, do 
you have a different explanation to offer for this difference?

> I am not so pessimistic about the general programming population that I
> assume that most of them are making this mistake, or that any particular
> programmer is making this mistake.

I am. I know that I myself have made this "mistake" numerous times: of 
deriving a descriptive stance from the imagery suggested by a canonical naive 
implementation story.

> Even if they were, how can using different terminology for the same
> concept in languages and operating systems possibly be helpful?

> I'm definitely not going to repeat every argument that I want to make
> about obj-cap systems using two different sets of terminology. It would
> be a waste of my time.

I agree. We should use the terminology connecting out field to that of 
object-oriented programming, since that's the "object" we mean by 
"object-capability model". I don't think Bill was suggesting otherwise. Bill?

> [*] The three approaches (not necessarily exhaustive) are:
>     - caller looks up method ID in a data structure associated with the
>       invoked object's concrete type.
>     - caller looks up (method ID, concrete type ID) in a global data
>       structure.
>     - caller calls a single entry point associated with the concrete
>       type, and that routine does different things depending on the
>       method ID.
>     All of these are potentially applicable to *all* object systems.

If the object's allocation unit includes the representation of the object's 
concrete type, whether a type ID, vtable, or whatever, then, in all of these, 
the allocation unit is the object. Two facets on the same composite would need 
different concrete type representations, and so would still need separate 
allocations. If the concrete type representation is moved into the pointer (as 
in KeyKOS keys or the fat pointer technique), then multiple facets of the same 
composite can share a single allocated record holding only the composite's state.

So this doesn't change your conclusion. I just wanted to be clear that the 
salient implementation choice is orthogonal from the one you explain above.

Text by me above is hereby placed in the public domain


More information about the cap-talk mailing list