[cap-talk] Domain change (IPC?) overhead

[Jonathan S. Shapiro]

On Tue, 2008-03-25 at 13:49 -0700, David Wagner wrote:
> In this case, I don't think DeepCopy is separable
> from the representation of the type, so I'm inclined to say it should
> work fine to have it be a type, not a type qualifier.

Umm. I think we crossed wires.

I'm imagining two calling conventions. One is used at a protection
domain boundary that is not a GC domain boundary. At such a boundary,
references can be passed directly. The other is called where a
separation between GC domains. At such a boundary, references must be
passed using deep copy. There is no change in the received object type;
it is a calling convention issue.

I was tacitly assuming that deep copy is not user-overridden. I
understand why, in some languages, that might be desirable, but I
offhand I do not see how a TCB-provided IDC primitive could be permitted
to rely on an application-provided implementation of deep-copy unless it
is implemented as (1) serialize to bytes (2) copy bytes in IDC (3)
deserialize back to object. Since this involved an additional data copy
in the deserialize step it is undesirable.

In the absence of user override, I think that DeepCopy can be a calling
convention qualifier (which is a form of type qualifier).


shap