Are Fibers just broken in D?

[Steven Schveighoffer]

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