[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
> 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
> - 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