On Aug 27, 2010, at 12:33 PM, Asher wrote:

> I want to know "where" on the C stack this "might" remain. It =
shouldn't be an obtuse question - Ruby is allocating each and every =
object, and I'm not using any C pointers for the particular example, so =
there is nothing else in my C stack (in this case, "I" don't have a C =
stack, only Ruby does).=20


So my question comes down to:

def random_method
  # demo_var is internally mapped as a pointer to the newly created =
Object, which is instantiated on the heap. =20
  demo_var =3D Object.new
  # demo_var is internally mapped to 4
  demo_var =3D nil
  # GC, in env_mark, walks (among others) space demarcated by =
RubyVM::Env, which is defined by its length in objects (VALUE)
  ObjectSpace.garbage_collect
end

So the environment's memory space is evaluated as a series of long =
values (which were allocated during the compilation of the iseq), each =
of which is potentially a pointer pointing to the heap.=20

So as I understand, before the GC is called here we have 2 NODE_LASGN =
nodes. Is this correct?=20

So the first one allocates Object and assigns the reference to demo_var =
in the local var table on the stack.=20

The second one assigns demo_var in the local var table on the stack to =
4.=20

So where does the GC discover a reference to Object to test in order to =
mark? It is clear that if a reference to Object is left (invisibly) on =
the stack then it will be marked until the stack gets cleaned up. This =
would obviously not take place until the frame is taken off the stack. =
But I can't find anywhere that this would make sense. The only place =
that I see where a reference occurs that the GC is walking is in the =
locals table. But the instruction for NODE_LASGN (setlocal) changes the =
pointer value for the local variable reference. So there _shouldn't_, so =
far as I can tell, be a reference to Object; yet insofar as Object gets =
marked by gc_mark_locations (called by gc_env_mark), it has a reference =
still existing.=20

Can anyone help me find where this reference is occurring? My read of =
the code suggests that the GC should get "4" for the slot that would =
have been a pointer to Object, yet this isn't what happens.=20

Insight appreciated.

Asher=