On 21 October 2012 21:01, Chris Muller <asqueaker at gmail.com> wrote:
>>> So, after several hours top still shows >500MB.  Will it ever go back
>>> down to the level reported by vm-parameters [1,2 or 3]?
>>
>> I'm not sure.  It all depends on the useMmap variable in the linux vm.  If
>> it is non-zero then a cursory reading of the source says that yes, the
>> memory should be returned.
>
> It appears Igor is right.  Even if I just do:
>
> Y:=String new: 550000000.
>
> and then:
>
> Y:=nil
>
> nothing I do other than rebooting the image seems to recover that
> memory for other processes.  But rebooting the image is not an option
> for a 24x7 server.
>
> I hope this can be fixed because it really neuters Squeak's ability to
> outshine other systems by its flexibility.
>
Unfortunately there is no easy fix , which will fit all possible use scenarios.
As you can see from comments in code, this feature was disabled on purpose
for cases when your application works extensively with external
resources/libraries,
which using malloc() a lot.

IMO, the right solution to this would be to employ a memory segments
model (which i talked before),
but that will mean a lot of refactorings in VM. But would allow much
better coexistance between
conventional C heap and object memory segments, which can be
allocated/deallocated dynamically.
The downside of it, is of course, that object memory address space
will be no longer continuous
(so you have to say bye to simple and inexpensive checks like
  oop < youngMemoryStart etc).
But the upside is to be able to have various kinds of memory segments,
like 'non-movable segment'
and 'read-only segments' etc..

To my thinking this is the right way to go.


-- 
Best regards,
Igor Stasenko.