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

Stu,

I've been pointing out this hole in the language for some time now.

It's a little bit related to "final blocks in packages", Mantis 878
  http://www.verilog.org/svdb/bug_view_page.php?bug_id=0000878
The intention of that is to allow singleton-based cleanup activities.

One might think that the hole isn't too bad.  Since SV doesn't have
automatic stack-based object allocation (like C++), there is
conversely no possibility of automatic stack-based cleanup.
Thus all objects allocated with "new" could be deallocated 
with something like "obj = null;".  Just prior to that explicit
deallocation, one could do something like "obj.cleanup();".

Unfortunately it's not quite so simple.  While SV provides
no implicit allocation of objects, it does provide plenty of
implicit deallocation of objects.  (i.e. all references to a
given object are lost.)  And there is no hook for objects to
perform self-cleanup in those cases.

This basically forces users into a disciplined coding style,
in which object ownership is strongly maintained and visible.
In such an environment explicit calls to object cleanup functions
would be possible, and could work reliably.

I think the language would be well-served by allowing classes
to optionally declare destructors which run when an object is
reclaimed by the system.  This would open up different and
useful object management possibilities in complex designs.

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 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.
> 
> 

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