Date: Tue Oct 11 2011 - 06:13:47 PDT
From Arturo's comments, it seems there's a bit of confusion regarding "reference counting." The proposal specifies only how proxy objects track references from importing languages and how proxy objects notify the exporting language that no import references remain. The proposal does not specify how the importing languages determine that they no longer reference the proxy object (and indirectly, the corresponding exported object), nor does it say how the exporting language determines whether or not to garbage-collect or delete the exported object when no more references remain from other languages. The other parts may or may not use reference counting within the individual languages, but that's up to the implementers of those languages.
[In this note, I'm going to use "import" to mean using an object or subroutine furnished by another language and "export" to mean furnishing an object or subroutine to be used by another language. This differs from our stated policy of using "import" and "export" solely with respect to SystemVerilog, but I think this is necessary in order to illustrate the symmetry of usage among the languages.]
As Vitaly has pointed out, at most one reference per importing language gets stored with each proxy object. Languages that export an object and connect to the proxy object do not call RegisterReference() on the proxy object; instead they call SetActualHandle() to register the unique connection of the proxy object to the exported object. Languages that "import" the object reference it only through the proxy object; when they first make the connection, they call RegisterReference() to register their own connection to the proxy object. Calling RegisterReference() a second time from the same language does not really create an additional reference.
Arturo has talked about using associative maps; what we are proposing is to have one associative map (from importing language to handle) for each exported object, and to have this associative map stored within the proxy object, so that its lifetime is coterminous with that of the proxy object.
After the importing language establishes a reference to a proxy object, it shall use its own mechanism of choice to determine when it has no further references to the imported (proxy) object. This could be a reference counting protocol, or stop, mark, and copy, or even user-specified deallocation (such as by using a C++ destructor). But whatever the mechanism is, it must implement the disconnect from the proxy object via a call to ClearReference(). And in turn, when ClearReference() determines that there are no remaining references from importing languages, it should call ClearReferenceAtActual() to notify the exporting language that the exported object no longer has any references from importing languages. Notice that ClearReferenceAtActual() is declared as pure virtual; the exporting language must provide a class type-specific implementation for each derived proxy object class. Thus, the implementation of ClearReferenceAtActual() is outside the scope of this proposal, and can do whatever the implementers of the exporting language deem to be the correct way of tracking the disappearance of references from other languages.
I will admit that we could explain this more clearly in the proposal, but I did want to deal directly with Arturo's questions about reference "counts" and memory management.
Jim Vellenga
Jim Vellenga | Member of Consulting Staff | Cadence
P: 978.262.6015 F: 978.262.6636 www.cadence.com<http://www.cadence.com>
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
