digitalmars.D.bugs - [Issue 15084] New: GC must ensure there is at least X% of free space
- via Digitalmars-d-bugs (25/34) Sep 18 2015 https://issues.dlang.org/show_bug.cgi?id=15084
https://issues.dlang.org/show_bug.cgi?id=15084 Issue ID: 15084 Summary: GC must ensure there is at least X% of free space in the heap after collection to avoid frequent collections Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nobody puremagic.com Reporter: dmitry.olsh gmail.com One thing that any remotely production-quality GC does is analyze the result of collection with respect to minimal headroom - X % (typically 30-50%). If we freed Y % of heap where Y < X, then the GC should extend the heap so that it get within X % mark of free space in the extended heap. See the exchange in NG discussion at http://forum.dlang.org/thread/mailman.149.1442256696.22025.digitalmars-d puremagic.com On 14-Sep-2015 21:47, H. S. Teoh via Digitalmars-d wrote:Over in the d.learn forum, somebody posted a question about poor performance in a text-parsing program. After a bit of profiling I discovered that reducing GC collection frequency (i.e., GC.disable() then manually call GC.collect() at some interval) improved program performance by about 20%.... On Monday, 14 September 2015 at 18:58:45 UTC, Adam D. Ruppe wrote:Definitely. I think it hits a case where it is right at the edge of the line and you are allocating a small amount. So it is like the limit is 1,000 bytes. You are at 980 and ask it to allocate 30. So it runs a collection cycle, frees the 30 from the previous loop iteration, then allocates it again... so the whole loop, it is on the edge and runs very often. Of course, it has to scan everything to ensure it is safe to free those 30 bytes so the GC then runs way out of proportion. Maybe we can make the GC detect this somehow and bump up the size. I don't actually know the implementation that well though.--
Sep 18 2015