[m-dev.] enabling stseg component by default

[Paul Bone]

On Wed, May 22, 2013 at 02:46:40PM +1000, Julien Fischer wrote:
>
> On Wed, 22 May 2013, Paul Bone wrote:
>
>>
>> There are three things I"m aware of:
>>
>>    1) You requested a way to get stats about memory zone usage, I never
>>       implemented this.
>>    2) The caching and freeing of zones (how many do we cache, what policy
>>       is used to prevent the cache from growing too large) has never been
>>       benchmarked/tuned.
>
> One thing we could do is add something to the stdlib's gc module that
> clears the zone cache, or possibly just extend gc.garbage_collect/[02]
> to do that.
>
> So far as tuning the other parameters you mention goes, we probably need
> to start using the stack segement grades more to do that ...
>

Yep.

2.5) Also, I don't recall testing if caching is of _any_ benifit, maybe in
     non-parallel grades it's cheaper just to free/drop the memory zone when
     it is released.

>>    3) I planned, but never implemented, per-engine caching of stack zones
>>       in parallel grades (in addition to a global cache).  My current
>>       thinking is that an engine should hang onto a small number of zones,
>>       1 or perhaps 2 so that if a process keeps crossing a zone threshold
>>       it doesn't need to bother the global cache often.  The local cache's
>>       data structure should also be very simple to make this operation as
>>       quick as possible.
>
> That's not really an important issue for the non-parallel grades! ;-)
>
> What I am aiming to do here is to make it less likely that users will
> bump into stack exhaustion problems due to the stacks in the non-stseg
> grades having a fixed size.

I thought so.


-- 
Paul Bone
http://www.bone.id.au