I might just add that there are some other important targets as well in the vein of this discussion.
DLL's *still* don't work properly. druntime/phobos still don't really work as dll's. They are getting some attention, but it's been a really long standing and seriously major issue. Shared libraries are like, important! On 25 May 2013 00:50, Manu <turkey...@gmail.com> wrote: > On 24 May 2013 20:24, Regan Heath <re...@netmail.co.nz> wrote: > >> On Fri, 24 May 2013 01:11:17 +0100, Manu <turkey...@gmail.com> wrote: >> >>> /agree, except the issue I raised, when ~ is used in phobos. >>> That means that function is now off-limits. And there's no way to know >>> which functions they are... >>> >> >> It's not the allocation caused by ~ which is the issue though is it, it's >> the collection it might trigger, right? >> > > Yes, but the unpredictability is the real concern. It's hard to control > something that you don't know about. > If the phobos function can avoid the allocation, then why not avoid it? > > > So what you really need are 3 main things: >> >> 1. A way to prevent the GC collecting until a given point(*). >> 2. A way to limit the GC collection time. >> 3. For phobos functions to be optimised to not allocate or to use alloca >> where possible. >> >> #1 should be trivial. >> > > I think we can already do this. > > #2 is much harder to achieve in the general case (I believe). >> > > The incremental(+precise) GC idea, I think this would be the silver bullet > for games! > > #3 is not essential but desirable and could be added/improved over time. >> > > Yes, I think effort to improve this would be universally appreciated. > > > (*) Until the collection point the GC would ask the OS for more memory (a >> new pool or page) or fail and throw an Error. Much like in Leandro's >> concurrent GC talk/example where he talks about eager allocation. >> > > Bear in mind, most embedded hardware does now have virtual memory, and > often a fairly small hard limit. > If we are trying to manually sequence out allocations and collects, like > schedule collects when you change scenes on a black screen or something for > instance, then you can't have random phobos functions littering small > allocations all over the place. > The usefulness of #1 depends largely on #3. > > > In order to make #2 easier to achieve I had an idea, not sure how workable >> this is.. >> >> Lets imagine you can mark a thread as not stopped by the pause-the-world. >> Lets imagine it still does allocations which we want to collect at some >> stage. How would this work.. >> >> 1. The GC would remove the thread stack and global space from it's list >> of roots scanned by normal collections. It would not pause it on normal >> collections. >> >> 2. (*) above would be in effect, the first allocation in the thread would >> cause the GC to create a thread local pool, this pool would not be shared >> by other threads (no locking required, not scanned by normal GC >> collections). This pool could be pre-allocated by a new GC primitive >> "GC.allocLocalPool();" for efficiency. Allocation would come from this >> thread-local pool, or trigger a new pool allocation - so minimal locking >> should be required. >> >> 3. The thread would call a new GC primitive at the point where collection >> was desired i.e. "GC.localCollect(size_t maxMicroSecs);". This collection >> would be special, it would not stop the thread, but would occur inline. It >> would only scan the thread local pool and would do so with an enforced >> upper bound collection time. >> >> 4. There are going to be issues around 'shared' /mutable/ data, e.g. >> >> - The non-paused thread accessing it (esp during collection) >> - If the thread allocated 'shared' data >> >> I am hoping that if the thread main function is marked as @notpaused (or >> similar) then the compiler can statically verify neither of these occur and >> produce a compile time error. >> >> So, that's the idea. I don't know the current GC all that well so I've >> probably missed something crucial. I doubt this idea is revolutionary and >> it is perhaps debatable whether the complexity is worth the effort, also >> whether it actually makes placing an upper bound on the collection any >> easier. >> >> Thoughts? > > > It sounds kinda complex... but I'm not qualified to comment. >
