<div dir="ltr">On 25 May 2013 05:05, H. S. Teoh <span dir="ltr"><<a href="mailto:hsteoh@quickfur.ath.cx" target="_blank">hsteoh@quickfur.ath.cx</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Fri, May 24, 2013 at 07:55:44PM +0200, deadalnix wrote:<br>

> On Friday, 24 May 2013 at 15:17:00 UTC, Manu wrote:<br></div><div class="im">
> >One important detail to consider for realtime usage, is that it's<br>
> >very unconventional to allocate at runtime at all...  Perhaps a<br>
> >couple of short lived temp buffers each frame, and the occasional<br>
> >change in resources as you progress through a world (which are<br>
> >probably not allocated in GC memory anyway).  Surely the relatively<br>
> >high temporal consistency of the heap across cycles can be leveraged<br>
> >here somehow to help?<br>
><br>
> That is good because it means not a lot of floating garbage.<br>
<br>
</div>Isn't the usual solution here to use a memory pool that gets deallocated<br>
in one shot at the end of the cycle? So during a frame, you'd create a<br>
pool, allocate all short-lived objects on it, and at the end free the<br>
entire pool in one shot (which could just be a no-op if you recycle the<br>
pool memory for the temp objects in the next frame). Long-lived objects,<br>
of course, will have to live in the heap, and since they usually aren't<br>
in GC memory anyway, it wouldn't matter.<br></blockquote><div><br></div><div style>This totally depends on the task. Almost every task will have its own solution. I think there are 3 common approaches though:</div><div style>
1. Just don't allocate. Seriously, you don't need dynamic memory anywhere near as much as you think you do. Get creative!</div><div style>2. Use a pool like you say.</div><div style>3. Use a scratch buffer or some sort. Allocate from this buffer linearly, and wipe it clean each frame. Similar to a pool but supporting irregularly sized allocations.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
A naīve, hackish implementation might be a function to reset all GC<br>
memory to a clean slate. So basically, you treat the entire GC memory as<br>
your pool, and you allocate at will during a single frame; then at the<br>
end of the frame, you reset the GC, which is equivalent to collecting<br>
every object from GC memory except it can probably be done much faster<br>
than a real collection cycle. Anything that needs to live past a single<br>
frame will have to be allocated via malloc/free. So this way, you don't<br>
need any collection cycle at all.<br></blockquote><div><br></div><div style>Problem with implementing that pattern in the GC, is it's global now.</div><div style>You can no longer choose the solution for the problem as such.</div>
<div style>How do you allocate something with long life? malloc?</div><div style>What do non-realtime threads to?</div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Of course, this may interact badly with certain language constructs: if<br>
any reference to GC objects lingers past a frame, you may break language<br>
guarantees (e.g. immutable array gets reused, violating immutability<br>
when you dereference the stale array pointer in the next frame). But if<br>
the per-frame code has no escaping GC references, this problem won't<br>
occur. Maybe if the per-frame code is marked pure? It doesn't work if<br>
you need to malloc/free, though (as those are inherently impure -- the<br>
pointers need to survive past the current frame). Can UDAs be used<br>
somehow to enforce no escaping GC references but allow non-GC references<br>
to persist past the frame?<br>
<span class=""><font color="#888888"><br>
<br>
T<br>
<br>
--<br>
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG<br>
</font></span></blockquote></div><br></div></div>