[sv-ec] RE: [sv-cc] FW: a question about system verilog class deconstructor

Actually this is not a DPI-specific problem at all.
The exact same thing can come up with PLI system tasks
that are called from within class methods.

Allowing classes to declare destructors would be a
solution to all such "resource-leak" problems.

Regards,
Doug 

> -----Original Message-----
> From: owner-sv-cc@server.eda.org 
> [mailto:owner-sv-cc@server.eda.org] On Behalf Of Stuart Sutherland
> Sent: Wednesday, January 10, 2007 10:27 AM
> To: sv-cc@server.eda.org; sv-ec@server.eda.org
> Subject: [sv-cc] FW: a question about system verilog class 
> deconstructor
> 
> All,
> 
> I am forwarding this suggestion that I received to both the CC and EC
> committees.  The suggestion is how to solve a problem with 
> memory management
> that affects the DPI, but the suggested solution probably under the EC
> umbrella.
> 
> Be sure to read the full message thread in the text below...
> 
> I'd like to hear thoughts from both committees on if this 
> suggestion would
> be beneficial.
> 
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> Sutherland HDL, Inc.
> stuart@sutherland-hdl.com
> 503-692-0898
> 
> 
> -----Original Message-----
> From: Feng Xian [mailto:alex.xian@gmail.com] 
> Sent: Wednesday, January 10, 2007 8:42 AM
> To: stuart@sutherland-hdl.com
> Subject: Re: a question about system verilog class deconstructor
> 
> Thanks for you reply Stuart. I imagine the easiest way to 
> solve this problem
> is to extend the class in SystemVerilog with a deconstructor function
> 'delete'. Before the object is trashed by SV, SV should call 
> user defined
> 'delete' function if there's one defined. In this way, user 
> will have a
> chance to clean up the mess he/she created and SV is not aware of. :) 
> 
> Alex
> 
> 
> On 1/10/07, Stuart Sutherland <stuart@sutherland-hdl.com> wrote:
> 
> -----Original Message-----
> From: Ralph Duncan [mailto:RDuncan@CloudShield.com] 
> Sent: Wednesday, January 10, 2007 9:21 AM
> To: stuart@sutherland-hdl.com
> Subject: RE: [sv-cc] FW: a question about system verilog 
> class deconstructor
> 
> Stu,
> 
> It was a deliberate, collective decision to let memory management on 
> either side of the DPI interface be decoupled.
> 
> The clearest statements appear in 26.4.1.4 (mirrored in F.5.7):
> "The memory spaces owned and allocated by the foreign code and 
> SystemVerilog code are disjoined...[the user should not] expect 
> SystemVerilog code to free the memory allocated by the foreign code."
> 
> Our compromise with string parameters reflects this (F.7.10), 
> choosing 
> to maintain strict separation of memory management at the 
> risk of perhaps
> encouraging leaks on the C side. [Doug Warmke may have 
> improvements to 
> this string materal that hasn't made it into the LRM yet.]
> 
> In Alex Xian's example, if an SV class object calls into C and 
> thereby creates a C++ object, then it is the user's responsibility to 
> deallocate that object before returning to SV from C space across the 
> DPI boundary or to deallocate it with a subsequent DPI call 
> into C space 
> before the class object ceases to exist.  Since the current 
> interface is
> defined for C (rather than C++) it would not be reasonable to expect 
> implicit DPI destructor calls.
> 
> Ralph Duncan
> Cloudshield Technologies
> Sunnyvale, CA
> Ralph.Duncan@cloudshield.com
> 
> 
> -----Original Message-----
> From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org]On
> Behalf Of Stuart Sutherland
> Sent: Wednesday, January 10, 2007 8:13 AM
> To: sv-cc@server.eda.org
> Subject: [sv-cc] FW: a question about system verilog class 
> deconstructor
> Importance: High
> 
> 
> 
> Can anyone respond to this question?
> 
> Thanks,
> 
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> Sutherland HDL, Inc.
> stuart@sutherland-hdl.com
> 503-692-0898
> 
> -----Original Message-----
> From: Feng Xian [mailto:alex.xian@gmail.com] 
> Sent: Wednesday, January 10, 2007 6:42 AM
> To: info@sutherland-hdl.com; stuart@sutherland-hdl.com
> Cc: Feng Xian
> Subject: a question about system verilog class deconstructor
> Importance: High
> 
> Dear Mr Stuart,
> 
> I have a question about the System Verilog's class memory 
> management. The
> class in system verilog only provide a constructor 'new' but not a
> deconstructor 'delete'. The LRM declares that 'SystemVerilog 
> manages all
> dynamic memory automatically.' in section 11.26. But this is 
> not the case
> when DPI is involved. A System Verilog class that uses DPI 
> potentially has
> other resources allocated in the C functions, e.g. memory 
> allocation (new a
> C++ object) or a TCP socket etc. When an instance of this 
> system verilog
> class is reclaimed by System Verilog's garbage collection 
> mechanism, there's
> no automatic way provided to let the class have an 
> opportunity to  call DPI
> to deallocate the resource  that DPI allocated previously. 
> For example, 
> 
> import "DPI" function chandle newCPlusPlusObj();
> import "DPI" function int CPlusPlusObjMethod(chandle obj);
> 
> class SvClass;
>     local chandle cppObj;
>     int retVal;
> 
>     function new(); 
>               cppObj = newCPlusPlusObj();    // this DPI call 
> will allocate
> a c++ object by using 'new' in c++ code wrapper
>     endfunction : new
> 
>     function doSth()
>              retVal = CPlusPlusObjMethod(cppObj); // this method may
> allocate more resources that SV is not aware of ( e.g. TCP 
> socket, etc.)
>              ....
>     endfunction : doSth
> 
> endclass : SvClass;
> 
> in caller
>           // a scope that uses SVClass
>           {
>           SvClass svObj;
>           svObj = new;     // create a new SvClass instance  
> which will call
> DPI to 'new' a C++ object 
>           ...
>           }
>           // scope closed, svObj is deallocated by System Verilog
> automatically, but C++ object leaked
> 
> 
> Is this a possible SystemVerilog design hole or you may have 
> other way to
> work around this? (Well, I am not talking about re-implement 
> C++ object in
> SV) 
> 
> Thanks in advance,
> 
> Alex
> 
> -- 
> Alex Xian
> ---------------------------------------------------------
> * The only thing constant in this world is Change
> * Attitude, after all, is everything 
> 
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
> -- 
> Alex Xian
> ---------------------------------------------------------
> * The only thing constant in this world is Change 
> * Attitude, after all, is everything 
> 
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.