[m-dev.] enabling stseg component by default
paul at bone.id.au
Wed May 22 14:54:27 AEST 2013
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
> 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/
> 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 ...
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.
More information about the developers