[sv-ec] 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.