Memory Notes

Call Stack

Environments must be created for each function call, to pass in parameters. Most have a lifetime of the function call only, but others are captured by lambdas. It is difficult to anticipate when one is no longer in use since even if it is not captured, a child enviornment may capture it and the whole chain must be preserved.

Copying: If we can determine when environments are captured (through some kind of reference couting) then on a capture event we could copy the temporary versions into actual enviornments. But once again the whole chain must be captured, and reference counting and tracking may be slower than automatic collection.

Automatic Collection: If garbage collection was trigged when an allocation failed, the garbage collection could trigger. This would clean up unused environments, but also introduce a delay to some allocations which would occur fairly regularly. (Whenever n function calls were made.)

This method is hard because the collection function doesn't have access to all the live objects in a given moment. For example, in the middle of parsing, objects are not arranged in one structure, but all throughout the call stack.

Sizing

While the main enviornment is guarenteed to be large, most environments are probably relatively small. However, some will still be large. Any series of lets or internal definitions will add to that functions environment.

Resizing

When environments are resized we allocate a new one. But all the other existing pointers (such as lambdas) can't see the new one and still point to the old one.

This is not solved by automatic collection. Instead we would end up with both copies.

Resize at garbage collection

Instead of resizing whenever, resizing would be restricted to collection time. At collection time a larger block in the to space could be allocated for the table, but would also require a reinsertion. This approach would work if environments change size gradually, but if they must suddenly adapt it might fill up.

Symbol Table The symbol table is just an index to symbols allocated in blocks. Because it manages its own memory, it can resize safely. Its lifetime is well understtod. The same may not work for environments since their lifetime is unpredictable.