On Monday, 18 August 2014 at 18:04:50 UTC, Ali Çehreli wrote:
On 08/18/2014 03:11 AM, Ivan Kazmenko wrote:
> my program usually hit an out-of-memory error very soon. It
> worked fine when compiled with 64-bit DMD but failed to
collect
> the garbage in time with 32-bit DMD and with recent LDC.
That sounds like a false pointer issue. D's current GC is
conservative: It takes any value that could be a pointer as a
pointer and persists the memory that is falsely being pointed
at.
The problem becomes 2^^32 times less likely when pointers are
64-bit wide.
Hmm, that might be it, thank you for the tip.
I suppose there is a way to disable scanning certain parts of
memory for possible pointers. Still, the core.memory
documentation speaks a lower-level language than I'm currently
familiar with. A quick look on your book's memory management
chapter provided some explanation but still didn't enlighten me
on this specific problem.
It looks like I want to have most of my data under something like
GC.BlkAttr.NO_SCAN. But I don't yet see a clean way to introduce
something like that in the code. It seems like I want a custom
allocator, but various pages show they existed in D1 and are now
deprecated in D2. And perhaps there is also a granularity
problem: I have classes containing structs and structs pointing
to classes, so struct data (single bytes to hundreds of bytes)
lies next to class pointers most of the time.
So, is there a tutorial on how to better hint the D garbage
collector?
Ivan Kazmenko.
