Out of memory error (even when using destroy())

[rikki cattermole via Digitalmars-d-learn]

On 26/05/2017 9:15 AM, realhet wrote:
> Thanks for the answer!
> 
> But hey, the GC knows that is should not search for any pointers in 
> those large blocks.
> And the buffer is full of 0-s at the start, so there can't be any 'false 
> pointers' in it. And I think the GC will not search in it either.
> 
> The only reference to the buffer is 'st' which will die shortly after it 
> has been allocated.
> 
> 64bit is not a solution because I need to produce a 32bit dll, and I 
> also wanna use 32bit asm objs.
> The total 2GB amount of memory is more than enough for the problem.
> My program have to produce 300..500 MB of continuous data frequently. 
> This works in MSVC32, but with D's GC it starts to eat memory and fails 
> at the 4th iteration. Actually it never releases the previous blocks 
> even I say so with destroy().
> 
> At this point I only can think of:
> a) Work with the D allocator but emulate large blocks by virtually 
> stitching small blocks together. (this is unnecessary complexity)
> b) Allocating memory by Win32 api and not using D goodies anymore (also 
> unnecessary complexity)
> 
> But these are ugly workarounds. :S
> 
> I also tried to allocate smaller blocks than the previous one, so it 
> would easily fit to the prevouisly released space, and yet it keeps 
> eating memory:
> 
> void alloc_dealloc(size_t siz){
>      auto st = new ubyte[siz];
> }
> 
> void main(){
>      foreach(i; 0..4) alloc_dealloc(500_000_000 - 50_000_000*i);
> }

If you have to use such large amounts frequently, you really have to go 
with buffers of memory that you control, not the GC. Memory allocation 
is always expensive, if you can prevent it all the better.