SystemVerilog’s Garbage Collection – Dont forget Threads !

Humans generally like symmetry. C++ has constructor and destructor. Memory allocated in the constructor is to be released in the destructor.

SystemVerilog is not so symmetrical in this context. Systemverilog has constructor but there is no destructor. The memory allocated to the object is garbage collected automatically.

Well in the context of VMM there are thousands of the transactions are created and typically handful of the transactors are created. While transactions don’t last the entire simulation time, typically transactors last the entire simulation time.

Now the transactions are data and they don’t have their own threads. So the garbage collection works perfect.

Now the Systemverilog in contrast to C++ has one more dimension. That is Thread. Class can have their own threads.  These threads are resources of the class that started it. Now what happens is if the thread is active even if the object handle is not referenced by any component the garbage collection will not happen till all threads are terminated.

Now one such scenario is hot plug systems. There could be a model that may have their own  threads. Now to detach and attach with the same class handle could lead to issues.

Since the class handle is not really freed up unless all threads of the class are completed.

VMM xactors have stop_xactor to address it. Although if the main of the xactor thread launched multiple threads by itself with the dangerous join_none will also have issues when the transactor needs to be stopped.

Stopping the xactor will be my next post.