From: Eric Hodel <drbrain@...7.net>
Date: 2007-09-28T07:05:19+09:00
Subject: Re: object_id 1, 2, 3

On Sep 27, 2007, at 10:11 , SpringFlowers AutumnMoon wrote:
> Eric Hodel wrote:
>>
>> You don't need to go quite so far.  OS X starts its heap at a low
>> memory address:
>>
>> $ ruby -ve "p ''.object_id"
>> ruby 1.8.6 (2007-09-23 patchlevel 5000) [powerpc-darwin8.10.0]
>> 1002180
>>
>> $ ruby -ve "p ''.object_id"
>> ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-freebsd6]
>> 67351450
>>
>> Also, the way ruby's heap is constructed, addresses will count down
>> then jump up to the next chunk of ruby heap slots (provided that no
>> GC is done):
>>
>> $ ruby -e "p %w[a b].map { |o| o.object_id }"
>> [1002060, 1002050]
>
> so the object_id can be just the memory location of the object?  does
> Ruby keep a table to tell whether it is a memory location as  
> opposed to
>
> irb(main):003:0> 1000000.object_id
> => 2000001

For non-symbols and non-fixnums, it is the memory location of the  
Object.

The table is:

static struct heaps_slot { /* ... */ } *heaps;

in gc.c.

> which is not a memory location... in other words, when Ruby tries to
> fetch the object, sometimes it will dereference 1002060 (fetch the
> content there) but sometimes it won't, but just pretend that it is an
> actual object?

See _id2ref in gc.c for how an id is turned into an Object.

> I just realize that what if we extend the class Fixnum to have an  
> extra
> instance variable

Instance variables are stored in a Hash that hangs off of the Object  
for struct RObject-backed objects.  There is a global hash for  
everything else.