www.digitalmars.com
C & C++
DMDScript
D Programming
digitalmars.D
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.ldc
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.ide
digitalmars.D.debugger
digitalmars.D.internals
digitalmars.D.dwt
digitalmars.dip.development
digitalmars.dip.ideas
D.gnu
D
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
Other
digitalmars.empire
digitalmars.DMDScript
electronics
<h2>digitalmars.D.learn - A question about moving GC</h2> <div id="PostingTOC"> <ul> <li> <a href="#N3492"> Max Samuha</a> (23/23) Jun 03 2006 How to ensure D code that interoperates with external libraries will </li> <ul> <li> <a href="#N3493"> Lars Ivar Igesund</a> (8/39) Jun 03 2006 The GC in Ares is currently the same as the one in Phobos, but the inter... </li> <li> <a href="#N3494"> Unknown W. Brackets</a> (4/35) Jun 03 2006 Typically, garbage collectors run only on memory </li> <ul> <li> <a href="#N3496"> Max Samuha</a> (23/27) Jun 03 2006 Thank you for prompt replies. Most programs will run more than one </li> <ul> <li> <a href="#N3497"> Unknown W. Brackets</a> (33/55) Jun 03 2006 Well, you are correct that you need to do this for threaded code </li> <ul> <li> <a href="#N3498"> Max Samuha</a> (7/40) Jun 04 2006 Thank you for the extensive explanation! </li> <ul> <li> <a href="#N3509"> Walter Bright</a> (5/10) Jun 07 2006 They will be pinned implicitly, no need to call pin/unpin. The only time... </li> <ul> <li> <a href="#N3510"> Stewart Gordon</a> (4/15) Jun 07 2006 Would it remain pinned indefinitely, until the C function exits, or </li> <ul> <li> <a href="#N3511"> Walter Bright</a> (3/18) Jun 07 2006 It's pinned because it's on the stack, just like pointers on the stack </li> <ul> <li> <a href="#N3513"> Unknown W. Brackets</a> (4/9) Jun 07 2006 Of course, how foolish of me - so there's no worry about the garbage col... </li> <ul> <li> <a href="#N3517"> Max Samuha</a> (5/15) Jun 08 2006 Thanks. It seems I can live with that for now. i can't help saying D </li> </ul> <li> <a href="#N3520"> Stewart Gordon</a> (5/11) Jun 08 2006 But what if the foreign code needs to hold onto the pointer for longer </li> <ul> <li> <a href="#N3528"> Walter Bright</a> (3/14) Jun 08 2006 Have the D caller code keep a copy, or use addRoots to tell the gc where... </li> <ul> <li> <a href="#N3529"> Unknown W. Brackets</a> (4/9) Jun 08 2006 But the question is for a "moving" GC, which might not consider a local </li> <ul> <li> <a href="#N3531"> Walter Bright</a> (2/4) Jun 09 2006 addroots will work with that. </li> <ul> <li> <a href="#N3533"> Unknown W. Brackets</a> (6/11) Jun 09 2006 But what if I don't know where the foreign code is holding it? The C </li> </ul> </ul> <li> <a href="#N3534"> Stewart Gordon</a> (12/18) Jun 09 2006 What is addRoot_s_? </li> <ul> <li> <a href="#N3535"> Walter Bright</a> (6/17) Jun 09 2006 First of all, the foreign code documentation ought to make some mention </li> </ul> </ul> </ul> <li> <a href="#N3537"> Bruno Medeiros</a> (7/26) Jun 09 2006 Whoa, I got a bit confused here. Is any reference that is held in the </li> <ul> <li> <a href="#N3539"> Walter Bright</a> (4/7) Jun 09 2006 Because then you'd have to track all the register contents instruction </li> <ul> <li> <a href="#N3561"> Bruno Medeiros</a> (6/16) Jun 12 2006 :/ I'm lost, I didn't understand that at all. "track all the register </li> <ul> <li> <a href="#N3565"> Daniel Keep</a> (25/39) Jun 12 2006 DISCLAIMER: /me is not an x86 assembler expert. Take with the requisite </li> <ul> <li> <a href="#N3571"> Bruno Medeiros</a> (6/42) Jun 12 2006 The very same thing can happen with references stored in the heap or the... </li> </ul> </ul> </ul> </ul> </ul> </ul> </ul> </ul> </ul> </ul> </ul> <li> <a href="#N3502"> Stewart Gordon</a> (7/10) Jun 06 2006 <snip> </li> <ul> <li> <a href="#N3503"> Max Samuha</a> (4/9) Jun 06 2006 Yes, the thread you mention was posted two years ago. It would be </li> </ul> </ul> </ul> </div> <div id="Posting"><div id="PostingHeading"><a name="N3492"> <a href="#N3493">reply</a> Max Samuha <maxter i.com.ua_spamless> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3492"> writes</a>:</a> </div> <pre> How to ensure D code that interoperates with external libraries will work when a moving gc is eventually used with D? Will i need to add lots of pinning/unpinning code? extern(C) external(Foo* foo); struct Foo { } class Bar { Foo foo; } main() { Foo* foo = new Foo(); // Should foo be pinned before the call? external(foo); Bar bar = new Bar(); // Should bar be pinned before the call? external(&bar.foo); } btw, ares seems to provides a moving gc and does have a gc.pin method. Should i consider looking closer at ares? Thanks </pre> <div id="PostingFooting"> Jun 03 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3493"> <a href="#N3494">next sibling</a> <a href="#N3492">parent</a> Lars Ivar Igesund <larsivar igesund.net> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3493"> writes</a>:</a> </div> <pre> Max Samuha wrote: <pre> How to ensure D code that interoperates with external libraries will work when a moving gc is eventually used with D? Will i need to add lots of pinning/unpinning code? extern(C) external(Foo* foo); struct Foo { } class Bar { Foo foo; } main() { Foo* foo = new Foo(); // Should foo be pinned before the call? external(foo); Bar bar = new Bar(); // Should bar be pinned before the call? external(&bar.foo); } btw, ares seems to provides a moving gc and does have a gc.pin method. Should i consider looking closer at ares? Thanks </pre> The GC in Ares is currently the same as the one in Phobos, but the interface in Ares should make it possible to easier switch between other types of GC's. -- Lars Ivar Igesund blog at http://larsivi.net DSource & <a href="https://www.google.com/search?q=site%3Adigitalmars.com%2Fd%2Farchives%2Fdigitalmars+D">#D</a>: larsivi </pre> <div id="PostingFooting"> Jun 03 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3494"><a href="#N3493">prev sibling</a> <a href="#N3502">next sibling</a> <a href="#N3492">parent</a> <a href="#N3496">reply</a> "Unknown W. Brackets" <unknown simplemachines.org> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3494"> writes</a>:</a> </div> <pre> Typically, garbage collectors run only on memory allocation/deallocation/similar. They won't run in the middle of a foreign program... unless it's threaded, then all bets are off. -[Unknown] <pre> How to ensure D code that interoperates with external libraries will work when a moving gc is eventually used with D? Will i need to add lots of pinning/unpinning code? extern(C) external(Foo* foo); struct Foo { } class Bar { Foo foo; } main() { Foo* foo = new Foo(); // Should foo be pinned before the call? external(foo); Bar bar = new Bar(); // Should bar be pinned before the call? external(&bar.foo); } btw, ares seems to provides a moving gc and does have a gc.pin method. Should i consider looking closer at ares? Thanks </pre> </pre> <div id="PostingFooting"> Jun 03 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3496"> <a href="#N3494">parent</a> <a href="#N3497">reply</a> Max Samuha <maxter i.com.ua_spamless> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3496"> writes</a>:</a> </div> <pre> On 2006年6月03日 11:09:56 -0700, "Unknown W. Brackets" <unknown simplemachines.org> wrote: <pre> Typically, garbage collectors run only on memory allocation/deallocation/similar. They won't run in the middle of a foreign program... unless it's threaded, then all bets are off. -[Unknown] </pre> Thank you for prompt replies. Most programs will run more than one thread, so it is not guaranteed that garbage collection will not be triggered when control is in external code. What's the best way to ensure that the pointers are valid until control is returned to D code? version (MovingGC/Ares/whatever) { gc.pin(foo); } external(foo); version (MovingGC/Ares/whatever) { gc.unpin(foo); } that's no good. D claims it is compatible with C code but it cannot be true unless either the specs require that D use only non-moving garbage collector or there is a standard way to ensure that pointers to garbage collected memory passed to external functions remain valid while control is in external code. please correct me if i missed something. sorry for my poor English </pre> <div id="PostingFooting"> Jun 03 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3497"> <a href="#N3496">parent</a> <a href="#N3498">reply</a> "Unknown W. Brackets" <unknown simplemachines.org> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3497"> writes</a>:</a> </div> <pre> Well, you are correct that you need to do this for threaded code interfacing with C functions via pointers. That doesn't mean D can't interface with C code properly, just that it might not properly do it, necessarily, under this circumstance. The truth of the matter is, D is still in development, and so is the standard library. This is something that has not yet been provided for, you are right. But, as yet, no D implementation uses a compacting GC. I would suggest that a compiler that adds a compacting GC in could, theoretically, detect the passing of a pointer to a C function, and automatically "pin" it before the call. Unpinning it afterward does not seem practical. Another option would be to declare the variable which holds the pointer as extern (C). This could be a clear indication to the compiler that this pointer should not be moved. However, the above solutions may indeed be impractical. More thought will be needed, and this thought will no doubt come from Walter. This is why, as I said, D is still in an alpha stage. Even so, I would personally just make a note near the affected area, e.g.: // !!! Passing a pointer to C. Or however you prefer to make such notes in your convention; possibly noting this specifically as something to check on whenever a new compiler is used. It may very well be that gc.pin() and gc.unpin() functions will be added to Phobos, in which case you will need to go through these areas and make the changes - just as I had to do with my code when on_scope_success was changed to scope (success), and when === was changed to is. It may seem like a pain, but the changes are typically minor, and the benefits I see from programming in D vs. C/C++ still far outweigh these problems. I cannot predict if it's the same for you, of course. I'm American, so I may have to ask you to forgive me my poor English as well. Yours is as good as mine, whether that's a compliment or an insult. -[Unknown] <pre> Thank you for prompt replies. Most programs will run more than one thread, so it is not guaranteed that garbage collection will not be triggered when control is in external code. What's the best way to ensure that the pointers are valid until control is returned to D code? version (MovingGC/Ares/whatever) { gc.pin(foo); } external(foo); version (MovingGC/Ares/whatever) { gc.unpin(foo); } that's no good. D claims it is compatible with C code but it cannot be true unless either the specs require that D use only non-moving garbage collector or there is a standard way to ensure that pointers to garbage collected memory passed to external functions remain valid while control is in external code. please correct me if i missed something. sorry for my poor English </pre> </pre> <div id="PostingFooting"> Jun 03 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3498"> <a href="#N3497">parent</a> <a href="#N3509">reply</a> Max Samuha <maxter i.com.ua_spamless> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3498"> writes</a>:</a> </div> <pre> On 2006年6月03日 17:06:03 -0700, "Unknown W. Brackets" <unknown simplemachines.org> wrote: <pre> Well, you are correct that you need to do this for threaded code interfacing with C functions via pointers. That doesn't mean D can't interface with C code properly, just that it might not properly do it, necessarily, under this circumstance. The truth of the matter is, D is still in development, and so is the standard library. This is something that has not yet been provided for, you are right. But, as yet, no D implementation uses a compacting GC. I would suggest that a compiler that adds a compacting GC in could, theoretically, detect the passing of a pointer to a C function, and automatically "pin" it before the call. Unpinning it afterward does not seem practical. Another option would be to declare the variable which holds the pointer as extern (C). This could be a clear indication to the compiler that this pointer should not be moved. However, the above solutions may indeed be impractical. More thought will be needed, and this thought will no doubt come from Walter. This is why, as I said, D is still in an alpha stage. Even so, I would personally just make a note near the affected area, e.g.: // !!! Passing a pointer to C. Or however you prefer to make such notes in your convention; possibly noting this specifically as something to check on whenever a new compiler is used. It may very well be that gc.pin() and gc.unpin() functions will be added to Phobos, in which case you will need to go through these areas and make the changes - just as I had to do with my code when on_scope_success was changed to scope (success), and when === was changed to is. It may seem like a pain, but the changes are typically minor, and the benefits I see from programming in D vs. C/C++ still far outweigh these problems. I cannot predict if it's the same for you, of course. I'm American, so I may have to ask you to forgive me my poor English as well. Yours is as good as mine, whether that's a compliment or an insult. -[Unknown] </pre> 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. </pre> <div id="PostingFooting"> Jun 04 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3509"> <a href="#N3498">parent</a> <a href="#N3510">reply</a> Walter Bright <newshound digitalmars.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3509"> writes</a>:</a> </div> <pre> Max Samuha wrote: <pre> 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. </pre> 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. </pre> <div id="PostingFooting"> Jun 07 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3510"> <a href="#N3509">parent</a> <a href="#N3511">reply</a> Stewart Gordon <smjg_1998 yahoo.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3510"> writes</a>:</a> </div> <pre> Walter Bright wrote: <pre> Max Samuha wrote: <pre> 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. </pre> 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. </pre> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means? Stewart. </pre> <div id="PostingFooting"> Jun 07 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3511"> <a href="#N3510">parent</a> <a href="#N3513">reply</a> Walter Bright <newshound digitalmars.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3511"> writes</a>:</a> </div> <pre> Stewart Gordon wrote: <pre> Walter Bright wrote: <pre> Max Samuha wrote: <pre> 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. </pre> 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. </pre> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means? </pre> 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. </pre> <div id="PostingFooting"> Jun 07 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3513"> <a href="#N3520">next sibling</a> <a href="#N3511">parent</a> <a href="#N3517">reply</a> Unknown W. Brackets <Unknown_member pathlink.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3513"> writes</a>:</a> </div> <pre> Of course, how foolish of me - so there's no worry about the garbage collector killing that in a threaded program either. Duh. -[Unknown] In article <e679ot7ドルe31ドル digitaldaemon.com>, Walter Bright says... <pre> Stewart Gordon wrote: <pre> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means? </pre> 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. </pre> </pre> <div id="PostingFooting"> Jun 07 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3517"> <a href="#N3513">parent</a> Max Samuha <maxter i.com.ua_spamless> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3517"> writes</a>:</a> </div> <pre> On Wed, 7 Jun 2006 22:11:52 +0000 (UTC), Unknown W. Brackets <Unknown_member pathlink.com> wrote: <pre> Of course, how foolish of me - so there's no worry about the garbage collector killing that in a threaded program either. Duh. -[Unknown] In article <e679ot7ドルe31ドル digitaldaemon.com>, Walter Bright says... <pre> Stewart Gordon wrote: <pre> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means? </pre> 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. </pre> </pre> Thanks. It seems I can live with that for now. i can't help saying D is very addictive. imho, the best C-like language i've had a chance to try. </pre> <div id="PostingFooting"> Jun 08 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3520"><a href="#N3513">prev sibling</a> <a href="#N3537">next sibling</a> <a href="#N3511">parent</a> <a href="#N3528">reply</a> Stewart Gordon <smjg_1998 yahoo.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3520"> writes</a>:</a> </div> <pre> Walter Bright wrote: <pre> Stewart Gordon wrote: </pre> <snip> <pre> <pre> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means? </pre> 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. </pre> But what if the foreign code needs to hold onto the pointer for longer than it can remain on the stack? Stewart. </pre> <div id="PostingFooting"> Jun 08 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3528"> <a href="#N3520">parent</a> <a href="#N3529">reply</a> Walter Bright <newshound digitalmars.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3528"> writes</a>:</a> </div> <pre> Stewart Gordon wrote: <pre> Walter Bright wrote: <pre> Stewart Gordon wrote: </pre> <snip> <pre> <pre> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means? </pre> 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. </pre> But what if the foreign code needs to hold onto the pointer for longer than it can remain on the stack? </pre> Have the D caller code keep a copy, or use addRoots to tell the gc where the foreign code is holding it. </pre> <div id="PostingFooting"> Jun 08 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3529"> <a href="#N3534">next sibling</a> <a href="#N3528">parent</a> <a href="#N3531">reply</a> Unknown W. Brackets <Unknown_member pathlink.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3529"> writes</a>:</a> </div> <pre> But the question is for a "moving" GC, which might not consider a local reference to mean "don't move it"...? -[Unknown] In article <e6abmn1ドルiaj1ドル digitaldaemon.com>, Walter Bright says... <pre> Stewart Gordon wrote: <pre> But what if the foreign code needs to hold onto the pointer for longer than it can remain on the stack? </pre> Have the D caller code keep a copy, or use addRoots to tell the gc where the foreign code is holding it. </pre> </pre> <div id="PostingFooting"> Jun 08 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3531"> <a href="#N3529">parent</a> <a href="#N3533">reply</a> Walter Bright <newshound digitalmars.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3531"> writes</a>:</a> </div> <pre> Unknown W. Brackets wrote: <pre> But the question is for a "moving" GC, which might not consider a local reference to mean "don't move it"...? </pre> addroots will work with that. </pre> <div id="PostingFooting"> Jun 09 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3533"> <a href="#N3531">parent</a> "Unknown W. Brackets" <unknown simplemachines.org> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3533"> writes</a>:</a> </div> <pre> But what if I don't know where the foreign code is holding it? The C library might not expose this, and then I'm out of luck... unless I can modify it, which I probably can't. But, this is all theoretical anyway. I can't even think of a library that keeps a pointer I give it. -[Unknown] <pre> Unknown W. Brackets wrote: <pre> But the question is for a "moving" GC, which might not consider a local reference to mean "don't move it"...? </pre> addroots will work with that. </pre> </pre> <div id="PostingFooting"> Jun 09 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3534"><a href="#N3529">prev sibling</a> <a href="#N3528">parent</a> <a href="#N3535">reply</a> Stewart Gordon <smjg_1998 yahoo.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3534"> writes</a>:</a> </div> <pre> Walter Bright wrote: <pre> Stewart Gordon wrote: </pre> <snip> <pre> <pre> But what if the foreign code needs to hold onto the pointer for longer than it can remain on the stack? </pre> Have the D caller code keep a copy, or use addRoots </pre> What is addRoot_s_? <pre> to tell the gc where the foreign code is holding it. </pre> How will I know where the foreign code is holding the pointer? Surely it makes more sense to add the pointer itself as a root. Moreover, the pinning methods'll need to be documented. So at the moment, I'm guessing that the following will implicitly pin a GC-allocated block: - storing a pointer to it in a union - having a pointer to it on the stack - adding it as a root Stewart. </pre> <div id="PostingFooting"> Jun 09 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3535"> <a href="#N3534">parent</a> Walter Bright <newshound digitalmars.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3535"> writes</a>:</a> </div> <pre> Stewart Gordon wrote: <pre> Walter Bright wrote: <pre> Stewart Gordon wrote: </pre> <snip> <pre> <pre> But what if the foreign code needs to hold onto the pointer for longer than it can remain on the stack? </pre> Have the D caller code keep a copy, or use addRoots </pre> What is addRoot_s_? </pre> http://www.digitalmars.com/d/phobos/std_gc.html <pre> <pre> to tell the gc where the foreign code is holding it. </pre> How will I know where the foreign code is holding the pointer? </pre> First of all, the foreign code documentation ought to make some mention of what it does with the pointer - after all, it must even if you malloc'd it so you know when and if you can ever free it. Have the D code caller call addRoot. </pre> <div id="PostingFooting"> Jun 09 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3537"><a href="#N3520">prev sibling</a> <a href="#N3511">parent</a> <a href="#N3539">reply</a> Bruno Medeiros <brunodomedeirosATgmail SPAM.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3537"> writes</a>:</a> </div> <pre> Walter Bright wrote: <pre> Stewart Gordon wrote: <pre> Walter Bright wrote: <pre> Max Samuha wrote: <pre> 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. </pre> 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. </pre> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means? </pre> 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. </pre> 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<a href="https://www.google.com/search?q=site%3Adigitalmars.com%2Fd%2Farchives%2Fdigitalmars+D">#D</a> </pre> <div id="PostingFooting"> Jun 09 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3539"> <a href="#N3537">parent</a> <a href="#N3561">reply</a> Walter Bright <newshound digitalmars.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3539"> writes</a>:</a> </div> <pre> Bruno Medeiros wrote: <pre> 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) ? </pre> Yes. <pre> If so, why is that, why wouldn't a moving collector move it? </pre> Because then you'd have to track all the register contents instruction by instruction. </pre> <div id="PostingFooting"> Jun 09 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3561"> <a href="#N3539">parent</a> <a href="#N3565">reply</a> Bruno Medeiros <brunodomedeirosATgmail SPAM.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3561"> writes</a>:</a> </div> <pre> Walter Bright wrote: <pre> Bruno Medeiros wrote: <pre> 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) ? </pre> Yes. <pre> If so, why is that, why wouldn't a moving collector move it? </pre> Because then you'd have to track all the register contents instruction by instruction. </pre> :/ 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<a href="https://www.google.com/search?q=site%3Adigitalmars.com%2Fd%2Farchives%2Fdigitalmars+D">#D</a> </pre> <div id="PostingFooting"> Jun 12 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3565"> <a href="#N3561">parent</a> <a href="#N3571">reply</a> Daniel Keep <daniel.keep.lists gmail.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3565"> writes</a>:</a> </div> <pre> Bruno Medeiros wrote: <pre> Walter Bright wrote: <pre> Bruno Medeiros wrote: <pre> 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) ? </pre> Yes. <pre> If so, why is that, why wouldn't a moving collector move it? </pre> Because then you'd have to track all the register contents instruction by instruction. </pre> :/ I'm lost, I didn't understand that at all. "track all the register contents instruction by instruction" ? </pre> 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: Now, you move this into the ESI pointer to dereference it. 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. 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/ </pre> <div id="PostingFooting"> Jun 12 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3571"> <a href="#N3565">parent</a> Bruno Medeiros <brunodomedeirosATgmail SPAM.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3571"> writes</a>:</a> </div> <pre> Daniel Keep wrote: <pre> Bruno Medeiros wrote: <pre> Walter Bright wrote: <pre> Bruno Medeiros wrote: <pre> 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) ? </pre> Yes. <pre> If so, why is that, why wouldn't a moving collector move it? </pre> Because then you'd have to track all the register contents instruction by instruction. </pre> :/ I'm lost, I didn't understand that at all. "track all the register contents instruction by instruction" ? </pre> 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: Now, you move this into the ESI pointer to dereference it. 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. 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! </pre> 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<a href="https://www.google.com/search?q=site%3Adigitalmars.com%2Fd%2Farchives%2Fdigitalmars+D">#D</a> </pre> <div id="PostingFooting"> Jun 12 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3502"><a href="#N3494">prev sibling</a> <a href="#N3492">parent</a> <a href="#N3503">reply</a> Stewart Gordon <smjg_1998 yahoo.com> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3502"> writes</a>:</a> </div> <pre> Max Samuha wrote: <pre> How to ensure D code that interoperates with external libraries will work when a moving gc is eventually used with D? Will i need to add lots of pinning/unpinning code? </pre> <snip> Pinning has been requested a few times on these 'groups. There has also been a discussion before on issues that still need to be addressed before a GC that moves stuff around will work: http://www.digitalmars.com/d/archives/26273.html Stewart. </pre> <div id="PostingFooting"> Jun 06 2006 </div> </div><div id="Posting"><div id="PostingHeading"><a name="N3503"> <a href="#N3502">parent</a> Max Samuha <maxter i.com.ua_spamless> <a href="https://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.learn&artnum=3503"> writes</a>:</a> </div> <pre> On 2006年6月06日 14:27:22 +0100, Stewart Gordon <smjg_1998 yahoo.com> wrote: <pre> Pinning has been requested a few times on these 'groups. There has also been a discussion before on issues that still need to be addressed before a GC that moves stuff around will work: http://www.digitalmars.com/d/archives/26273.html Stewart. </pre> Yes, the thread you mention was posted two years ago. It would be really nice to hear a word from Walter on this issue. </pre> <div id="PostingFooting"> Jun 06 2006 </div> </div> <div id="footer_ad"> <br><br><br><br> </div> </div></div><div class="naked_ctrl"> <form action="/index.cgi/speech" method="get" name="gate"> <p><a href="http://altstyle.alfasado.net">AltStyle</a> によって変換されたページ <a href="https://digitalmars.com/d/archives/digitalmars/D/learn/3492.html">(->オリジナル)</a> / <label>アドレス: <input type="text" name="naked_post_url" value="https://digitalmars.com/d/archives/digitalmars/D/learn/3492.html" size="22" /></label> <label>モード: <select name="naked_post_mode"> <option value="default">デフォルト</option> <option value="speech" selected="selected">音声ブラウザ</option> <option value="ruby">ルビ付き</option> <option value="contrast">配色反転</option> <option value="larger-text">文字拡大</option> <option value="mobile">モバイル</option> </select> <input type="submit" value="表示" /> </p> </form> </div> </body></html>