|Jeroen Demeyer on Tue, 04 Apr 2017 10:26:58 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: When enlarging stack in new_chunk_resize(), add 1/8 to stack size|
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.