[ruby-core:31939] Variable Allocation, Variable Reassignment, GC Pointer Testing (Was: Re: Garbage Collection Question)

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


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.  
  demo_var = Object.new
  # demo_var is internally mapped to 4
  demo_var = 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. 

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

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

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

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. 

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. 

Insight appreciated.

Asher