D on next-gen consoles and for game development

[Manu]

On 25 May 2013 05:05, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:

> On Fri, May 24, 2013 at 07:55:44PM +0200, deadalnix wrote:
> > On Friday, 24 May 2013 at 15:17:00 UTC, Manu wrote:
> > >One important detail to consider for realtime usage, is that it's
> > >very unconventional to allocate at runtime at all...  Perhaps a
> > >couple of short lived temp buffers each frame, and the occasional
> > >change in resources as you progress through a world (which are
> > >probably not allocated in GC memory anyway).  Surely the relatively
> > >high temporal consistency of the heap across cycles can be leveraged
> > >here somehow to help?
> >
> > That is good because it means not a lot of floating garbage.
>
> Isn't the usual solution here to use a memory pool that gets deallocated
> in one shot at the end of the cycle? So during a frame, you'd create a
> pool, allocate all short-lived objects on it, and at the end free the
> entire pool in one shot (which could just be a no-op if you recycle the
> pool memory for the temp objects in the next frame). Long-lived objects,
> of course, will have to live in the heap, and since they usually aren't
> in GC memory anyway, it wouldn't matter.
>

This totally depends on the task. Almost every task will have its own
solution. I think there are 3 common approaches though:
1. Just don't allocate. Seriously, you don't need dynamic memory anywhere
near as much as you think you do. Get creative!
2. Use a pool like you say.
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.

A naīve, hackish implementation might be a function to reset all GC
> memory to a clean slate. So basically, you treat the entire GC memory as
> your pool, and you allocate at will during a single frame; then at the
> end of the frame, you reset the GC, which is equivalent to collecting
> every object from GC memory except it can probably be done much faster
> than a real collection cycle. Anything that needs to live past a single
> frame will have to be allocated via malloc/free. So this way, you don't
> need any collection cycle at all.
>

Problem with implementing that pattern in the GC, is it's global now.
You can no longer choose the solution for the problem as such.
How do you allocate something with long life? malloc?
What do non-realtime threads to?

Of course, this may interact badly with certain language constructs: if
> any reference to GC objects lingers past a frame, you may break language
> guarantees (e.g. immutable array gets reused, violating immutability
> when you dereference the stale array pointer in the next frame). But if
> the per-frame code has no escaping GC references, this problem won't
> occur. Maybe if the per-frame code is marked pure? It doesn't work if
> you need to malloc/free, though (as those are inherently impure -- the
> pointers need to survive past the current frame). Can UDAs be used
> somehow to enforce no escaping GC references but allow non-GC references
> to persist past the frame?
>
>
> T
>
> --
> People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130525/41945c4a/attachment-0001.html>