Walter Bright wrote:
> Stewart Gordon wrote:
>> Walter Bright wrote:
>>> Max Samuha wrote:
>>>> Thank you for the extensive explanation!
>>>> Marking my code with '// !!! Passing a pointer to C.' is what i've
>>>> been doing recently:) and it seems the best solution for now until
>>>> ares is mature or phobos has pin/unpin, or pointers passed to C are
>>>> pinned implicitly.
>>>
>>> They will be pinned implicitly, no need to call pin/unpin. The only time you're going to have a problem is if the C routine hides the pointer in a malloc'd buffer where the gc won't see it. The gc *will* see pointers on the C stack.
>>
>> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means?
> 
> It's pinned because it's on the stack, just like pointers on the stack for your D functions. The gc doesn't know the difference.

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) ? If so, why is that, why wouldn't a moving collector move it?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

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.

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" ?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

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/

Daniel Keep wrote:
> 
> 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!
> 

The very same thing can happen with references stored in the heap or the static segment (i.e. globals). That is, with *any* reference.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D