The full suite of mark routines comprising the functionality of the Garbage Collector's mark/sweep is now complete. Unit tests have been included to verify the functionality of marking shaka::Vector and shaka::Closure objects. While mark_call_frame() was not explicitly tested, it's functionality has been confirmed via the execution of the following code in the main REPL executable with mark/sweep running in the background:
(define (f proc) (f 'b) 'a)=> <#procedure>(define (id x) x)=> <#procedure>(f id) => a(call/cc f) => b
That last line of (call/cc f), while seemingly innocuous at first glance, implicitly involves an indecent amount of complex processes and register manipulations happening behind the scenes within the Virtual Machine. First, a continuation instance of a Closure object is created and passed as the single argument to the Closure object bound to f in the VM's environment. Inside of the body of f, this continuation is called on the Symbolb, which results in the evaluation of the body of the continuation, leading to a jump through the stack of CallFrames, and various other complex register reassignments. The integrity of the entire REPL system, including Parser, MacroContext, Compiler, and HeapVirtualMachine remained well intact after numerous other lines of code were executed, each followed by immediate calls to mark() and sweep(). I would say that barring any insidious and/or highly cryptic bugs, this serves to confirm the functionality of the Garbage Collector as it exists in its current form. Please review this Pull Request at your earliest convenience and let me know if you have any questions/concerns about the code presented herein.
Hello All,
The full suite of mark routines comprising the functionality of the Garbage Collector's mark/sweep is now complete. Unit tests have been included to verify the functionality of marking
shaka::Vector
andshaka::Closure
objects. Whilemark_call_frame()
was not explicitly tested, it's functionality has been confirmed via the execution of the following code in the main REPL executable with mark/sweep running in the background:(define (f proc) (f 'b) 'a)
=> <#procedure>
(define (id x) x)
=> <#procedure>
(f id) => a
(call/cc f) => b
That last line of
(call/cc f)
, while seemingly innocuous at first glance, implicitly involves an indecent amount of complex processes and register manipulations happening behind the scenes within the Virtual Machine. First, a continuation instance of aClosure
object is created and passed as the single argument to theClosure
object bound tof
in the VM's environment. Inside of the body off
, this continuation is called on theSymbol
b
, which results in the evaluation of the body of the continuation, leading to a jump through the stack ofCallFrames
, and various other complex register reassignments. The integrity of the entire REPL system, includingParser
,MacroContext
,Compiler
, andHeapVirtualMachine
remained well intact after numerous other lines of code were executed, each followed by immediate calls tomark()
andsweep()
. I would say that barring any insidious and/or highly cryptic bugs, this serves to confirm the functionality of the Garbage Collector as it exists in its current form. Please review this Pull Request at your earliest convenience and let me know if you have any questions/concerns about the code presented herein.Cheers, Troy