Well, you said "today you can do" as a general advice so I assumed you try to show us "how simple it is to do it by hand", not "how easy it is to make sth only for internal usage".
About this object being a ref one --- no, please read my comment again. Long story short: ref object can be deepCopied, your example cannot.
Besides: no, that's not the same. Why? Because GC finalizes a pointer. So it will finalize it when it comes to the conclusion it should free the memory for a pointer. It cares not about how huge memory block on shared heap it corresponds to nor think whenever shared heap should be cleaned at all. So you could have 90% of the shared heap filled with unused arrays and GC saying "Why free anythin? I've still got plenty of space on my thread's heap!" because pointers themselves are very small. That's the same I've told you about CUDA memory. Simply put: you don't have a GC-ed shared heap. You have an illusion of GC-ed shared heap.
Right it seems like there are a bunch of getOccupiedMem in the gc file so that it can get the memory managed, including a collection threshold.
In my case the shared mem array is only used to hold temporaries for computation (main long-lived data is held in a seq) so I can trigger a manual GC_collect after computation is done, but for non-temporary usage I could get out-of-mem even though enough space can be collected.
@mratsim Well, if you call GC_collect manually then it's much worse than manual allocation and deallocation from memory pool, I guess.
Could you explain further what getOccupiedMem changes in the case we were talking about (ref to ptr to memory external to thread heap)?