On 4/24/18 10:16 AM, Radu wrote:
On Tuesday, 24 April 2018 at 13:36:48 UTC, Steven Schveighoffer wrote:
On 4/24/18 5:11 AM, bauss wrote:
On Tuesday, 24 April 2018 at 07:58:01 UTC, Radu wrote:
On Tuesday, 24 April 2018 at 00:46:39 UTC, Byron Heads wrote:
[...]
This is not a fiber issue but a more memory management issue. Your
run out of address space on win32, the GC will not always collect
all those 99999 fibers that you allocate in that loop. As an
exercise replace `auto` with `scope` like `scope foo = new Foo();`
in that loop - you should see different results.
This shouldn't be a requirement, the 32-bit GC is generally not this bad.
Allocating so many fibers in a loop produces an OOM error on win32,
that's a fact! Event though it doesn't always happen you often get OOM
errors with the program above.
I'm not saying it doesn't happen, just that it *shouldn't* happen. At
least not for small sized chunks like this.
I want to emphasize that the program is allocating and releasing to the
GC 1 fiber at a time -- loop or no loop, this should work (more or less)
reliably, or Win32 has some more serious issues.
This isn't even a case of multi-threading, there are no extra threads here.
Probably the cause is related to how often the collection kicks in in
relation to the pages allocated via VirtualAlloc. But still, the issue
OP raised is not a Fiber related issue but a memory management issue.
Collections usually happen more often than they should. The biggest
issue with 32-bit arch is that random stack data often keeps large
blocks of memory from being collected. As those build up, the situation
gets worse until you have no more memory left.
But smaller chunks like a 16k Fiber stack should work without issues.
It should be simple to prove, instead of allocating a fiber, allocate a
similar sized chunk of bytes.
-Steve
