20,741
edits
Nasal GC Musings: Difference between revisions
Jump to navigation
Jump to search
m
→incremental GC
m (→incremental GC) |
|||
| Line 67: | Line 67: | ||
an incremental garbage collector can help improve performance by spreading out the work of garbage collection over multiple small increments rather than performing it all at once. This can help prevent stuttering and make the garbage collection process more deterministic. | an incremental garbage collector can help improve performance by spreading out the work of garbage collection over multiple small increments rather than performing it all at once. This can help prevent stuttering and make the garbage collection process more deterministic. | ||
The developer of Nasal, Andy Ross, originally considered implementing an incremental garbage collection scheme in Nasal. The idea was to perform garbage collection normally, but to check timestamps periodically and interrupt the garbage collection process if it exceeded a certain threshold. This would allow the garbage collector to continue its work in the background, rather than blocking the program until it had finished. | The developer of Nasal, Andy Ross, originally considered implementing an incremental garbage collection scheme in Nasal. The idea was to perform garbage collection normally, but to check timestamps periodically and interrupt the garbage collection process if it exceeded a certain threshold (then longjmp() out of it past some threshold, leaving the intermediate sweep stuff in place.). This would allow the garbage collector to continue its work in the background, rather than blocking the program until it had finished. | ||
However, implementing an incremental garbage collection scheme in Nasal would require additional steps to ensure that all objects are properly collected. For example, it would be necessary to track mutated reference-storing objects in a separate list so that they can be swept again. Additionally, a heuristic would be needed to determine when it is safe to restart the sweep and continue garbage collection. | However, implementing an incremental garbage collection scheme in Nasal would require additional steps to ensure that all objects are properly collected. For example, it would be necessary to track mutated reference-storing objects in a separate list so that they can be swept again. Additionally, a heuristic would be needed to determine when it is safe to restart the sweep and continue garbage collection. | ||
Overall, implementing an incremental garbage collection scheme in Nasal would be a complex undertaking that would require careful design and implementation. It is not clear whether the benefits of an incremental garbage collection scheme would outweigh the additional complexity and overhead that it would introduce. | Overall, implementing an incremental garbage collection scheme in Nasal would be a complex undertaking that would require careful design and implementation. It is not clear whether the benefits of an incremental garbage collection scheme would outweigh the additional complexity and overhead that it would introduce. | ||
the current Nasal GC implementation does not include a maximum delay and restart facility. If it did, that would entirely satisfy the current performance/stuttering issues. | |||
One idea discussed on the mailing list was adding timestamps to the data | |||
blocks and by making sure new blocks are inserted at the beginning of | |||
the linked list is would be easy to do something like this for the | |||
garbage collector: | |||
* process the linked list every second up to the point that timestamps get older than 8 seconds. | |||
* process blocks that are older than 8 second and less than 1 minute every minute. | |||
* treat blocks that are older than 1 minute as semi-permanent and only process them incrementally with (say) 16 blocks at a time. | |||
It might spread the load a little that way. | |||
== concurrent GC == | == concurrent GC == | ||