From: Logan Capaldo <logancapaldo@...>
Date: 2006-06-03T03:25:02+09:00
Subject: Re: How can I pin a Ruby object in memory?


On Jun 2, 2006, at 4:44 AM, Mauricio Fernandez wrote:

> 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
>

Interesting. (-- takes notes --). Almost seems like cheating :). But  
in a good way. I'm going to have read gc.c. Speaking of reading ruby  
source, is there an order you would recommend? Every time I look at  
it I get overwhelmed by a) not knowing where to start and b) K&R C. I  
can power-through the K&R C for the most part I think, but figuring  
out what to read when is tougher.