Hi,

"On top of that, Ruby is greedy with memory—it doesn’t hand the memory back to the OS after the request."

Just to elaborate on the above statement :

Basically the GC allocates an initial heap space of 10k slots.Each slot is large enough to hold an object.Whenever the first heap is maxed, a GC run triggers, attempts to free more space and eventually allocates another heap area if free slots is less than 4096.

The second time this happens, another 10k slots is made available.Additional heaps from this point onwards is allocated in slabs of ( last heap size allocated * 1.8 ).This is why jumps from 70MB RSS to 120MB RSS etc. is so common.

Ruby uses the libc memory allocation functions malloc, realloc, calloc etc.Stock malloc implementations don't return allocated memory back to the OS until the running process exits.This is an optimization to save on syscalls (brk) and to ensure relatively fast alloc/dealloc during the process lifetime.

The JVM for example allocates a memory region of 168MB with mmap on startup, which pretty much assigns all memory management tasks to the various GC implementations for the runtime.This platform, and JRuby for that matter, doesn't have this 'greedy' behavior and it'll just be able to return memory allocated during an intense spike back to the OS.

- Lourens