GC allocation issue

[Rene Zwanenburg]

On Thursday, 20 March 2014 at 20:48:18 UTC, Etienne wrote:
> I'm running some tests on a cache store where I planned to use 
> only Malloc for the values being stored, I'm hoping to 
> eliminate the GC in 95% of the program, but to keep it only for 
> actively used items..
>
> My problem is: when the program reaches 40MB it suddenly goes 
> down to 0.9MB and blocks.
>
> From every resource I've read, the understanding that came out 
> is that the GC will stop all threads and search for pointers 
> for data that was allocated only by the GC (using addRange or 
> addRoot to extend its reach). This means that in the worst case 
> scenario, there could be leaks, but I'm seeing the data being 
> deleted by the GC so I'm a little stomped here. What am I 
> missing?
>
> I'm using FreeListAlloc from here:
> https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/utils/memory.d#L152
> in here:
> https://github.com/globecsys/cache.d/blob/master/chd/table.d#L1087
> and this is how I made it crash:
> https://github.com/globecsys/cache.d/blob/master/chd/connection.d#L550
>
> I know it's the GC because using GC.disable() fixes it, so I'm 
> only really asking if the GC has a habit of deleting mallocated 
> data like this.

The strings returned by to!string are owned by the GC. Since the 
GC doesn't scan malloc'ed memory, the GC thinks all your 'values' 
are unreferenced. The keys are still referenced in the keys array.

So, it's GC-owned memory referenced only through malloc'ed memory 
that is being freed. Not the malloc'ed memory itself.

Also, not relevant for your current problem, but keep in mind 
that structs defined inside a function will have access to the 
function's locals. To avoid corruption when the function returns 
the stack frame will be allocated on the GC heap when an instance 
is created. Make your 'A' struct static to avoid this.