[Vm-dev] Setting minimum time threshold before freeing memory?

[Eliot Miranda]

_,,,^..^,,,_ (phone)

> On Mar 20, 2020, at 11:36 PM, Phil B <pbpublist at gmail.com> wrote:
> 
> 
> Eliot,
> 
>> On Sat, Mar 21, 2020 at 12:53 AM Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>  
>> Hi Phil,
>> 
>> 
>> > On Mar 20, 2020, at 10:57 AM, Phil B <pbpublist at gmail.com> wrote:
>> > 
>> > 
>> > I've been noticing at times that the VM seems to churning a bit re: allocating and freeing memory.  Granted, this is due to the workload I'm throwing at it (i.e. periodically perform a task that creates a number of Forms which are short-lived, for example) but it seems a tad aggressive on the free side.  What I'm wondering is if there's a VM parameter to slow down the rate at which it will free up memory? (i.e. alloc whenever needed, but free no sooner than X seconds after the last alloc)
>> 
>> There are two main parameters.  One is the size of eden.  Make this 64Mb (default 4mb 32-bits, 8Mb 64-bits).  The second is the GC growth ratio (can’t remember the name but it is assigned in setGCParameters).  This determines how much growth in heap size there is before a full GC kicks in.  If your usage is bursty then setting this high is probably a good idea.
> 
> Is the 'survivor count tenuring threshold' (parm 6) the other one you're referring to? (If so I'm not familiar with it... can you point me to 'David's paper' referred to in the method comment?)

Generation Scavenging: A non-disruptive high performance storage reclamation algorithm

https://people.cs.umass.edu/~emery/classes/cmpsci691s-fall2004/papers/p157-ungar.pdf

> 
> More info about my setup in case it helps:  A while back (several years ago) I started modifying my images to use the following values:
> 
> Smalltalk
>     vmParameterAt: 24
>     put: 268435456;
> 
>     vmParameterAt: 25
>     put: 134217728;
> 
>     vmParameterAt: 45
>     put: 67108864. 
> 
> It used to be the next time I'd restart my image after saving, those settings would work.  However the VM (5.0-202002190233) doesn't seem to be taking two of these settings anymore. 

That’s right.  The Spur GC is very different to the V3 GC, and the object representation is substantially improved too.  You should abandon any settings from V3. Spur is a different beast.

> Not sure when it changed/broke, but currently despite the above settings the image reports:
> 
> Smalltalk vmParameterAt: 24. "33554432"
> Smalltalk vmParameterAt: 25. "16777216"
> Smalltalk vmParameterAt: 45. "67108864"
> Smalltalk vmParameterAt: 44. "49546912"
> 
> The VM does appear to be doing an alloc/free of 16MB every couple/few seconds when it gets into this state.

That’s right.  You can set the heap growth factor and the shrink threshold.  Look at the VM parameters tab in the About Squeak report and read the comments in vmParameterAt:[put:].

> 
> So it looks like I have two problems:
> 
> 1) The VM appears to no longer take my memory threshold/headroom settings.  Are these values now too large or are there now other parms I need to change related to these settings? (i.e. are these still the right settings to be fiddling with?)

The entire memory management architecture is changed.  For example, the heap is now segmented and can grow and shrink using memory mapping to add and free settings. If you search for Cog & Spur you should be able to find lots of helpful material.

> 
> 2) In the event that the VM is right at the edge of needing more memory (briefly), the VM allocs/frees blocks of RAM continuously.  Is VM parm 6 the right setting to tweak to try to minimize this? (if so, seems like a tough value to get right for  workloads where the object sizes can shift around depending on what the image is doing)

I can’t remember what parameter 6 is off hand. Enlighten me?

> 
>> 
>> HTH
>> 
>> _,,,^..^,,,_ (phone)
> 
> Thanks,
> Phil 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200322/12078e3c/attachment.html>