Julia’s GC still has a long way to go. ideas/information on the state of Julia’s GC appreciated.
I know some of these ideas will add LOTS of works. This is not supposed to be a list of things that MUST be done, but things that COULD be done.
My idea is to divide memories into pools. Objects that can be handled by simpler GC like reference counting or just compile-time ownership semantics may be separately managed. I’m not sure if it will work though.
The GC is already using memory pools for different generations of memory (short, mid, long term), depending on how old an allocation is. Compile time known allocations that have a known finite lifetime don’t need to (and already aren’t) managed by GC - if the semantics guarantee that the allocation will be dead after a certain point and it’s known that the allocation doesn’t escape, it’s already allocated on the stack (or maybe even in registers only).
https://docs.julialang.org/en/v1/devdocs/gc/
https://github.com/JuliaLang/julia/pulls?q=is%3Aopen+is%3Apr+label%3AGC
Please be more specific when starting a discussion about Julia internals.
I had some “ideas” about GC as a novice and asked the experts to kindly explain why the problems are harder than I would expect here.
I’d encourage you to read their responses because, I assure you, the folks working on this have thought of almost every idea a novice could come up with. If a novice have an idea that might be novel, it’s on us to do the reading and research to actually show that the approach is novel so we don’t waste the time of the people who are already in the trenches.
From my point of view a hard time limit (configurable) on the time that the GC blocks the world would be desirable. And I don’t think that this would be that difficult to implement, but I am not a GC expert.
Regarding reference counting (and slightly off-topic): Is there (or should there be) reference counting in a package (or Base?), to avoid allocations (and hence GC) by re-using memory? Cf. my question in Reference counting and disposables