[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Thu Oct 26 17:18:22 UTC 2017
https://issues.dlang.org/show_bug.cgi?id=17914
Martin Nowak <code at dawg.eu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |code at dawg.eu
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 <code at dawg.eu> ---
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?
--
More information about the Digitalmars-d-bugs
mailing list