itsme213 wrote:

>>a is mapped to a VALUE. VALUEs are pointers to Ruby Object Structs.
>>Immediate objects are not represented by any Ruby Object Struct -- they
>>are identified directly by the pointer's destination. If Ruby sees such
>>a special pointer it does not need to resolve it.
> 
> Fine. As long as we understand that the immediate object is not the value
> stored in variable a, but the _implicit_ object that resides at the
> destination pointed to by 'a'. This is just to have a consistent underlying
> explanation:

I dislike this whole "stored at" model. It's too complex. Let's express 
it this way:

variables are names for Objects. In Ruby's implementation Objects are 
represented by VALUEs.

>>Because there is no actual Ruby Object Struct there are no flags (which
>>means you can't (un)taint them), no instance variables
> 
> No instance variables ... unless created by Ruby code would be better.

They're not saved in the Object struct, however. They're stored externally.

> How are floats and bignums represented?

Pointers to RFloat (klass, flags, value as double) and RBignum (klass, 
flags, sign, length, pointer to digits). Whenever you create a new Float 
or Bignum you get a new Object.

>>false, nil and true and the special undef value that is not visible
>>anywhere in Ruby are represented by VALUEs of 0, 2, 4 and 6.
> 
> false, true, and nil are objects _referred to_ by 0, 2, 4, 6. Same reason as
> above.

I have no idea what distinction you are trying to make there.

> Does object.id generally correspond to the way a reference to object is
> represented? What are the exceptions?

I think .object_id just returns the destination of the VALUE pointer as 
a Numeric. Don't trust me on this, though.

>>Symbols are represented by VALUEs with bit 0 to 7 set to 01110000. This
>>means that there can be up to 16777216 different Symbols on 32 bit and
>>up to 72057594037927936 different Symbols on 64 bit systems.
> 
> Presumably the symbols themselves (or their corresponding strings) are
> allocated somewhere within, or mapped from, the address block with that
> 0...7bit mask?

No, the remaining bits are used for storing the symbol ID which is based 
on the symbol type (global, instance variable...), an id counter and 
some bit shifting. Don't ask me why the symbol ID is generated that way. 
  I don't know. There's two tables, one for going from a String to a 
symbol ID and one for the other way. Those are used for Symbol#inspect 
and so on.