On Wednesday, 4 May 2022 at 15:04:13 UTC, cc wrote:
The MemUtils package offers a `ScopedPool` utility that seems
interesting. It isn't well documented however so I have no
idea if it actually works like I expect. I presume this would
work something akin to a VM memory snapshot/rollback for the
GC? It would be pretty handy for some scenarios, say a
serialization library. You specify a snapshot point (add a
pool to the stack?), incur all your GC allocations necessary
for generating the structure of your serialized data (which go
into the pool instead of the GC proper?), then you write it to
disk and pop the stack, effectively rolling back to the
original memory state of your program's GC. As long as you
make sure not to leak anything allocated within that phase,
seems like a good deal.
https://code.dlang.org/packages/memutils
Interesting.
My idea was ... objects marked as 'inscope' would be GC allocated
in a LIFO region of the heap, rather than the general GC pool.
Explicately deallocating such objects at end of scope then
becomes a no brainer for the GC (since 'inscope' would ensure at
compile time that no pointers/aliasing outside of that scope
could exist).
The LIFO would also avoid the problem of fragmentation (i.e. if
the objects were allocated in the general GC pool instead of a
separate pool).
This would give the programmer 'scope-based deallocation of GC
allocated memory'.
