-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bearophile wrote: > div0: >> The trouble with a moving garbage collector is that you have to be able >> to accurately scan the stacks of all threads. This is difficult to do >> with a language that can arbitrarily call into functions provided by >> different languages for which the compiler won't and can't have stack >> layout info. > > All pointers are to pinned memory. You can't give or receive an "unpinned > reference" >to an external function written in other languages. Only the D GC manages references > to unpinned classes. So, can you explain me what problems you see? > > Bye, > bearophile
Well on windows, in a single threaded application your stack usually looks like this: ==== Stack start D runtime start up - - - - - - void main(...) - your application stack - - - - - - DispatchMessage - win32 call * * * * windowProc - your D application window callback proc - - - - - - - - SendMessage - win32 call * * * * windowProc - another D application window callback proc - - - - - - - - Where - is D stack and * is unknown stack (usually win32 functions) Any part of the stack used by D code might and probably will have pointers to unpinned objects. In order to move an object you must be able to update all pointers to it, otherwise obviously your application is going to crash. There is no reasonable way to known anything about the parts of the stack indicated by *, including really where they start or end once you start talking about nested callbacks. You can't easily or reasonably find the bits of the stack used by D code, so you can't scan the stack, and therefore you can't move any object. Throw threading into the mix and your stacks get even more complicated. This isn't strictly a windows problem though. There are quite a few C libraries which use a callback mechanism and they'll all suffer from the same problem. This is part of the reason why you have to jump through hoops to call native code from Java or C#. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLtQ6xT9LetA9XoXwRArr/AJ9vjoD4T2FwXpLELNOeN1daQkmUmwCfWrju LmqQCmws/TX8wOSNaNh7I6A= =VH1s -----END PGP SIGNATURE-----
