<div dir="ltr">I might just add that there are some other important targets as well in the vein of this discussion.<div><br></div><div>DLL's *still* don't work properly. druntime/phobos still don't really work as dll's.</div>
<div>They are getting some attention, but it's been a really long standing and seriously major issue. Shared libraries are like, important!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 25 May 2013 00:50, Manu <span dir="ltr"><<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On 24 May 2013 20:24, Regan Heath <span dir="ltr"><<a href="mailto:regan@netmail.co.nz" target="_blank">regan@netmail.co.nz</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Fri, 24 May 2013 01:11:17 +0100, Manu <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
/agree, except the issue I raised, when ~ is used in phobos.<br>
That means that function is now off-limits. And there's no way to know<br>
which functions they are...<br>
</blockquote>
<br></div>
It's not the allocation caused by ~ which is the issue though is it, it's the collection it might trigger, right?<br></blockquote><div><br></div></div><div>Yes, but the unpredictability is the real concern. It's hard to control something that you don't know about.</div>
<div>If the phobos function can avoid the allocation, then why not avoid it?</div><div class="im"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So what you really need are 3 main things:<br>
<br>
1. A way to prevent the GC collecting until a given point(*).<br>
2. A way to limit the GC collection time.<br>
3. For phobos functions to be optimised to not allocate or to use alloca where possible.<br>
<br>
#1 should be trivial.<br></blockquote><div><br></div></div><div>I think we can already do this.</div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
#2 is much harder to achieve in the general case (I believe).<br></blockquote><div><br></div></div><div>The incremental(+precise) GC idea, I think this would be the silver bullet for games!</div><div class="im"><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
#3 is not essential but desirable and could be added/improved over time.<br></blockquote><div><br></div></div><div>Yes, I think effort to improve this would be universally appreciated.</div><div class="im"><div><br></div>
<div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(*) 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.<br></blockquote>
<div><br></div></div><div>Bear in mind, most embedded hardware does now have virtual memory, and often a fairly small hard limit.</div><div>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.</div>
<div>The usefulness of #1 depends largely on #3.</div><div class="im"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In order to make #2 easier to achieve I had an idea, not sure how workable this is..<br>
<br>
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..<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
4. There are going to be issues around 'shared' /mutable/ data, e.g.<br>
<br>
- The non-paused thread accessing it (esp during collection)<br>
- If the thread allocated 'shared' data<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thoughts?</blockquote><div><br></div></div><div>It sounds kinda complex... but I'm not qualified to comment.</div></div></div></div>
</blockquote></div><br></div>