Date: Wed Oct 12 2011 - 05:37:57 PDT
Arturo, once again I'd like to talk about the approach we're proposing, which (as I understand) differs from what you would like to take. But I think it's a reasonable approach -- as is yours.
Our goal has been to provide language implementers with enough information so that they can do the memory management without requiring them to do it in any one particular way. For this reason, we provide mechanisms for an importing language to
1) ask the exporting language to create and return a pointer to a new reference object,
2) notify the exporting language that no importing language is still holding on to a reference object
3) make requests of an object already furnished by the exporting language.
4) accept a pointer to a new or existing object returned by the exporting language in response to a request (such a s a subroutine call).
As you have observed, this does beg some questions, such as
a) What does the exporting language do with a notification that no importing language is still referring to the reference object?
b) How does an importing language know if a returned pointer matches one it already knows about?
-c)If it does match, how does the importing language know what level of inheritance to treat it as?
Our approach has been not to specify how the language implementers must do this, but rather to ask if the set is complete enough to do what needs to be done. For SystemVerilog, "what needs to be done" is defined by the proposed extensions to Clause 35.
I don't have time at the moment to explore all these questions in detail, but I do refer once again to the examples I posted on October 5 as evidence that they can be dealt with successfully.
But I did want to put forward this specific limitation of model as one which is a reasonable choice.
Jim Vellenga
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Wednesday, 12 Oct 2011 2:32 AM
To: Jim Vellenga; SV-CC (sv-cc@eda.org)
Subject: RE: DPI-OO reference "counts"
Jim,
I understand the basic mechanism. I believe you misunderstood my point about "reference counts". What you describe for the proxy class is indeed a reference counting scheme: The proxy class maintains a reference count of the (singleton) references per language. That's what I meant by reference count. What is still unclear is when the various methods are called by either a garbage-collected language (which may use reference counts or mark-and-sweep schemes) or languages that perform explicit (de)allocation. Under what conditions does the LRM guarantee that a previously imported object renders the same handle? Does that include the case when the handle may be unreachable but not yet reclaimed? How do we guarantee pointer equivalence without maintaining at least one reference beyond the lifetime of the object? Unless these guarantees are made explicit and clear, I am very unsure how to implement and support this. The answer I seem to hear is that the semantics fall out of the implementation, and I have a problem with such an approach.
In addition I have specific issues with the proposed implementation scheme:
1) I believe that maintaining a associative map within each import/export object seems somewhat expensive - I don't see why this needs to be the case.
2) I don't understand why the RegisterReference, ClearReference, and ClearReferenceAtActual must be implemented as methods. In particular, a single ClearAtActual per-language virtual method (the language being the object to which the handle is passed) could be used instead. Having these as methods of the import object is only one possible implementation, but not the only one.
3) What is the purpose of ClearReferenceAtActual? It's semantics are undefined, so what is the exporting language to do with such a call?
4) Presumably all calls to/from the exporting language (exporting in the general sense) must be trapped in order to remap actual arguments of (handle) object type to the corresponding language, but who is responsible for doing that mapping, and how is the per-language dispatching performed?
5) Fundamentally, why does all this need to be exposed in the user view? Why can't this be handled "under the hood" by the implementation?
I recognize that a lot of this is coming happening a bit late, but I had hoped that we could flush all this out during the regular detailed review. Unfortunately, that did not happen and left me with plenty of questions. Part of the problem is that proposal is massive and involves a fair amount of complexity (fie to the nature of what we're trying to do).
Arturo
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Jim Vellenga
Sent: Tuesday, October 11, 2011 6:14 AM
To: SV-CC (sv-cc@eda.org)
Subject: [sv-cc] DPI-OO reference "counts"
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<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
