IDs are used to identify a specific objects and methods to the ORB. Each address space has its own object ID space. Methods are identified by index within an interface. Interfaces and struct types are merely objects that implement specific introspection interfaces, and thus share the object ID space. Applications interact with objects via pointers (or references, or whatever else is appropriate for the language), not IDs. Thus, the marshalling stubs accept all object references in pointer form, rather than ID form. The language mapping ensures that the ID can be found from the pointer in a manner consistent with the platform ABI. Typically, it is stored as some fixed offset of the first word of the entity pointed to. Objects are not assigned IDs until they are passed to the ORB. When marshalling such an object, an ID is assigned from the local numberspace (high-bit clear) by marshalling code. The ID and an SHA-1 hash of the list of interfaces associated with the object (hereafter, the "interface hash") are passed to the "new object" syscall. The ID is stored into the object for future use. When presenting the object to the destination address space, the ORB needs to convert the local object ID to the object ID in the server's ID space. If the object has not yet been used in that address space, there will be no local ID (or pointer) associated with it. If this is the case, an ID in the remote numberspace (high-bit set) will be created by the ORB, and the object will be on the receiver's newobj list. The receiver can retrieve the interface hash with Marshalling code will maintain a wrapper object for every remote ID, as well as an ID-to-pointer lookup table for both local and remote objects. Each local and remote object contains two reference counts -- local and orb. The local reference count