On Tuesday, 3 August 2021 at 14:34:19 UTC, Steven Schveighoffer wrote:>
On 8/3/21 5:15 AM, Gregor Mückl wrote:>
The D garbage collector seems reasonable for applications with small (object sized) allocations. But that changes when you allocate large blocks of memory: due to a bug internal to the tracking of allocated pages, performance gradually degrades over time. So if you have to allocate large(ish) buffers regularly, it'll show over time. I reported that bug here with a repro case, but it didn't get any attention yet:
I haven't managed to understand thag part of the GC enough to submit a patch myself :(.
Is that repro case doing what you think it is doing? It appears to keep adding more and more larger allocations to the mix.
It seems you are calculating a
size variable and never using it.
I think possibly you meant to use
size * 1024 * 1024 instead of
i * 1024 * 1024.
In regards to the conservative nature of the GC, the larger the blocks get, the more chances they get "accidentally" pointed at by the stack (or some other culprit). 64-bit memory space should alleviate a lot of this, but I think there are still cases where it can pin data unintentionally.
I apologize for not replying earlier. I was very busy with real life stuff since I posted this.
Also, I feel REALLY embarrassed. You are right. I am sorry for wasting time with this. I was 100% certain that my code was right when I opened the bug report and I am sure that I checked it multiple times. But going back to the example program I have locally, it clearly contains this stupid bug.
I fixed the allocation size as you said and now I can't reproduce the behavior I remember. I've checked several dmd builds between 2.088 and 2.096 again and it doesn't show.
So the GC is just fine after all - and I've made an idiot of myself. Again.