Re: When enlarging stack in new_chunk_resize(), add 1/8 to stack size

[Jeroen Demeyer <jdemeyer@cage.ugent.be>]

On 2017-04-03 21:36, Bill Allombert wrote:
> This increases the risk the random gc run in a tight loop.

Tight gc loops are bugs and should be fixed regardless. In the past, I 
have reported several such bugs already.

> Maybe explain with word what behaviour you want to implement.

First of all, I never liked the stack doubling because it could lead to 
needless failures. Imagine for example that the stack is 4G and that 6G 
is available in total. With the old code, the doubling would fail and 
the stack would never be larger than 4G even if 6G is available. By 
increasing the stack in smaller pieces, this problem is avoided.

In current master, you correctly identified an issue that the stack 
could easily be completely full after calling new_chunk(). That could 
lead to doubling the stack twice in a row.

My current patch fixes both these issues: whenever the stack needs to be 
increased, some spare space (1/9 of the total stack) will be added. This 
spare space is large enough to avoid a lot of small allocations but 
small enough not to waste too much space.

> But your patches has the effect to require more stack increase in
> general.

I don't see that as a problem. In some cases (when you do a single large 
allocation), there will be *less* stack increases needed.