From: Mauricio Fernandez <mfp@...>
Date: 2006-06-02T17:44:46+09:00
Subject: Re: How can I pin a Ruby object in memory?

On Fri, Jun 02, 2006 at 04:57:54PM +0900, Logan Capaldo wrote:
> On Jun 1, 2006, at 8:23 PM, John Lam wrote:
> 
> >So I would guess that Ruby memory allocation is relatively expensive?
> >Certainly nowhere near as fast as allocating memory off of the "end"
> >of the heap or the stack, right? Does it have to search a free list of
> >blocks itself or does it delegate allocation to the system's malloc()
> >implementation?
> 
> Speaking without any knowledge of ruby's internals I imagine it's  
> actually is just allocating from the end of some pre-allocated buffer  
> until it reaches the end of the buffer. So if you never run out of  
> room in the buffer the allocation is just incrementing a pointer.  
> When you reach the end you do the first GC and subsequent allocations  
> have to search the freelist for a big enough chunk.

Ruby does not use a compacting GC and doesn't manage memory itself (the way a
normal memory allocator does) either.
There are two parts to allocating an object:
* each non-immediate object takes a sizeof(RVALUE)-sized slot (typically 20
  bytes) from one of the heaps managed by ruby (look for RVALUE and heaps in
  gc.c). It's sizeof(RVALUE) for any object so there's no problem with "chunk
  sizes" and fragmentation (iow. all chunks are ~20 bytes long). A freelist
  is used to find unused slots in said heaps. Additional heaps of increasing
  size will be created when there are no free slots or too few were freed in a
  GC run.
* most objects need additional memory (pointed to by fields in their
  corresponding slots): instance variable tables, char* for Strings, VALUE*
  for Arrays... these are allocated with malloc and will be freed when the
  corresponding object is reclaimed.

ruby relies on malloc(3) for low-level allocation, instead of doing it all
with sbrk(2) and friends.

-- 
Mauricio Fernandez  -   http://eigenclass.org   -  singular Ruby