https://issues.dlang.org/show_bug.cgi?id=17914
Martin Nowak <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Summary|Accidental per-process |[Reg 2.075] Fibers guard |limit of fiber uses |page uses a lot more memory | |mappings --- Comment #2 from Martin Nowak <[email protected]> --- Here is what I'm seeing, calling mprotect splits the mapped range into 2, a 16K rw--- and a 4K ----- mapping. Calling GC.collect finalizes all unreachable Fibers and unmaps *both* regions with a single `munmap(p, 20K)` call, so we don't really leak anything here. What's actually causing the limit is the fact that the kernel can no longer merge the mappings, hence the limit gets reached much quicker. foreach (i; 0 .. 32 * 1_024) { new Fiber(function{}, 4 * 4096, 0); } 00007f63304e9000 123184K rw--- [ anon ] vs. foreach (i; 0 .. 32 * 1_024) { new Fiber(function{}, 3 * 4096, 4096); } 00007f2819cbf000 12K rw--- [ anon ] 00007f2819cc2000 4K ----- [ anon ] 00007f2819cc3000 12K rw--- [ anon ] 00007f2819cc6000 4K ----- [ anon ] 00007f2819cc7000 12K rw--- [ anon ] 00007f2819cca000 4K ----- [ anon ] 00007f2819ccb000 12K rw--- [ anon ] 00007f2819cce000 4K ----- [ anon ] 00007f2819ccf000 12K rw--- [ anon ] 00007f2819cd2000 4K ----- [ anon ] 00007f2819cd3000 12K rw--- [ anon ] 00007f2819cd6000 4K ----- [ anon ] I'd err on the side of memory safety. Stack overflows are an actual problem with Fibers and hard&time-consuming to debug. For using 32K+ Fibers it doesn't seem too reasonable to use custom stack and guard sizes, e.g. a fairly big default stack size without guard page would prevent most issues. Any better idea to detect/prevent stack overflows? --
