Semantics of VALUE

Ruby
1

First off, I’d like to check this observation with folks on the list:

VALUEs today in Ruby are (sometimes) pointers to objects, and since
those objects don’t (today) move in memory, we can assume that they
are invariant for the lifetime of the process.

If that is true today, then here’s an interesting implication:

In future implementations of Ruby where presumably Ruby objects will
be managed by more sophisticated GC’s which do move objects in
memory when collecting, this will potentially impact the semantics of
VALUE. What happens to existing C-based extensions which assume the
current semantics of VALUE in a world where objects move?

In the CLR, we have a type called a GCHandle which lets us get a
reference to an object that can be manipulated directly by unmanaged
code - sometimes this can even involve pinning the object in memory
for the lifetime of the GCHandle.

Are the semantics of VALUE doc’d somewhere?

Thanks
-John

2

On Aug 15, 2006, at 11:22 AM, John L. wrote:

memory when collecting, this will potentially impact the semantics of
VALUE. What happens to existing C-based extensions which assume the
current semantics of VALUE in a world where objects move?

a VALUE won’t be a VALUE then anymore. I imagine the whole api would
have to change.

In the CLR, we have a type called a GCHandle which lets us get a
reference to an object that can be manipulated directly by unmanaged
code - sometimes this can even involve pinning the object in memory
for the lifetime of the GCHandle.

Are the semantics of VALUE doc’d somewhere?

There’s README.EXT

3

Thanks, Logan!

-John