A question about moving GC

[Daniel Keep]

Bruno Medeiros wrote:
> Walter Bright wrote:
>> Bruno Medeiros wrote:
>>> Whoa, I got a bit confused here. Is any reference that is held in the
>>> stack automatically pinned (i.e., the referred data doesn't move) ?
>>
>> Yes.
>>
>>> If so, why is that, why wouldn't a moving collector move it?
>>
>> Because then you'd have to track all the register contents instruction
>> by instruction.
> 
> :/ I'm lost, I didn't understand that at all. "track all the register
> contents instruction by instruction" ?

DISCLAIMER: /me is not an x86 assembler expert.  Take with the requisite
grain of salt.

Think about it like this: say you want to dereference a pointer.  Let's
assume you've got something like this:

# ubyte* foo = dontPointThatAtMe();
# ubyte firstFoo;

Now, you move this into the ESI pointer to dereference it.

# asm { mov ESI, [foo]; } // move contents to foo into ESI register

And then HOLD IT!  Moving garbage collector coming through!  Hmm, this
"foo" thing could be moved to be more efficient; let's move it!  Now, go
back to your business.

# asm { mov firstFoo, [ESI]; } // deref pointer in ESI

What happen?  Someone set up us the access violation!  That damned
moving GC preempted us and moved our data before we could get to it!

Even if you're not multi-threaded, this is still a problem: there's
nothing to preclude a pointer being stored in a register, calling new,
causing a moving collect, and then attempting to dereference it.

Isn't memory management fun? :P

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/