This Pull Request sets into place the initial scaffolding of the suite of mark procedures that will comprise the overall mark algorithm used by the Garbage Collector system to perform mark and sweep. Most of the methods are void stubs, save for the mark_node(const GCNode& node) procedure, for which I have partially implemented and tested its functionality. The mark_node() procedure can already handle the proper marking of complex DataPair structures, including cyclic ones, and when used in unison with the gc::GC::sweep() method, is able to properly reclaim any unused memory in the system.
You will notice in unit-GCMark.cpp, that prior to performing mark and sweep the number of allocated objects far outweighs the number of explicit calls made to create_node() in each of the test cases. However, once a mark/sweep cycle has been performed, the number of allocated objects in the GC's managed memory is exactly the number of explicit calls made to create_node(), which is good.
The excessive allocations are due to copy constructor invocations that are happening behind the scenes, I believe due to the handling of a shaka::DataPair() parameter being passed into the call to create_node(). Where the copy constructor calls are actually happening is difficult for me to determine at a cursory glance, and will likely require in-depth tracing to reveal.
That being said, it appears that by doing mark and sweep, we are able to free all of the garbage memory generated by calls to create_node() that are internal to the copy constructor of class DataPair. Please review this PR and let me know if you feel there is anything that I have missed. The rest of the work of the core systems team over the coming week will be to fill in the body of the stub procedures and incrementally iterate on their functionality while writing test cases to verify them.
Hello All,
This Pull Request sets into place the initial scaffolding of the suite of mark procedures that will comprise the overall mark algorithm used by the Garbage Collector system to perform mark and sweep. Most of the methods are void stubs, save for the
mark_node(const GCNode& node)procedure, for which I have partially implemented and tested its functionality. Themark_node()procedure can already handle the proper marking of complexDataPairstructures, including cyclic ones, and when used in unison with thegc::GC::sweep()method, is able to properly reclaim any unused memory in the system.You will notice in
unit-GCMark.cpp, that prior to performing mark and sweep the number of allocated objects far outweighs the number of explicit calls made tocreate_node()in each of the test cases. However, once a mark/sweep cycle has been performed, the number of allocated objects in theGC's managed memory is exactly the number of explicit calls made tocreate_node(), which is good.The excessive allocations are due to copy constructor invocations that are happening behind the scenes, I believe due to the handling of a
shaka::DataPair()parameter being passed into the call tocreate_node(). Where the copy constructor calls are actually happening is difficult for me to determine at a cursory glance, and will likely require in-depth tracing to reveal.That being said, it appears that by doing mark and sweep, we are able to free all of the garbage memory generated by calls to
create_node()that are internal to the copy constructor ofclass DataPair. Please review this PR and let me know if you feel there is anything that I have missed. The rest of the work of the core systems team over the coming week will be to fill in the body of the stub procedures and incrementally iterate on their functionality while writing test cases to verify them.Cheers,
Troy