Won a programming contest using D - Thank you for the tool!

[Ivan Kazmenko via Digitalmars-d]

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.