[Vm-dev] Re: Only ever grows? (was: Re: [squeak-dev] how/where is memory returned to the OS?)

Chris Muller asqueaker at gmail.com
Mon Oct 22 15:27:30 UTC 2012

> Eliot is referring to Ian Piumarta's explanation in sqUnixMemory.c here:
>     /* Note:
>      *
>      *   The code allows memory to be overallocated; i.e., the initial
>      *   block is reserved via mmap() and then the unused portion
>      *   munmap()ped from the top end.  This is INHERENTLY DANGEROUS since
>      *   malloc() may randomly map new memory in the block we "reserved"
>      *   and subsequently unmap()ped.  Enabling this causes crashes in
>      *   Croquet, which makes heavy use of the FFI and thus calls malloc()
>      *   all over the place.
>      *
>      *   For this reason, overallocateMemory is DISABLED by default.
>      *
>      *   The upshot of all this is that Squeak will claim (and hold on to)
>      *   ALL of the available virtual memory (or at least 75% of it) when
>      *   it starts up.  If you can't live with that, use the -memory
>      *   option to allocate a fixed size heap.
>      */
> See also the man page for sbrk for some related cautions about mixing malloc
> with lower level allocation/deallocation calls.

If the VM starts wth a block initially allocated for the
object-memory, and extended as needed for subsequent allocation
(String new: 4000000), but THEN reduced once not needed -- why would a
*subsequent* malloc call grabbing memory from the part that was
deallocated cause a crash?  At first I thought the crash would occur
after a subsequent extension of object-memory into memory that was
malloc'd for another purpose (plugin) but..  that could happen on the
_first_ time it is extended, couldn't it?


I start out using 40MB for object memory.


Plugins make some malloc calls, which allocate somewhere just above..


Now I need more allocation for object memory, so I'm trampling what
the plugin malloc'd?

Sorry, I unfortunately do not know C at all, thanks for helping me
understand the situation.

> Chris, may I ask why you see this as a problem? Is there some practical
> situation in which you are running out of real system memory as a consequence
> of the memory mapping strategy?

I have a Squeak-based server where 99% of requests are small, but once
a big request comes in, that server image jumps from 40MB to 400MB.
The extra memory was only needed for 10 seconds but unfortunately sits
there unused forever-after.  So it's almost like a memory-leak where
the only way to recover it is to bounce the server.

What would be worse is if the over-allocated image then affects GC
performance.  I'm still trying to figure out whether this is the case
-- it seems like not thank goodness.  Do you know for sure the answer
to that?  IOW should full GC's be just as fast after the big request
is long-gone (reclaimed) as they were before the big request?


More information about the Vm-dev mailing list