On 20 April 2014 06:56, via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

I think it would be useful to be able to mark structs as @nogc_alloc or something similar.

Interpretation: this struct and any data directly reachable from it is guaranteed to not be GC allocated. Then a precise collector could avoid scanning those and pointers to them.

Why wouldn't precise GC be able to do this anyway? It already has data about everything it scans. It can easily produce a 'don't bother scanning this' bit at the start of that data without programmer assistance?

Even with @nogc threads for audio/visual real time computations the GC itself will have to get down to consistent < 50-200ms freezes to get fluid interaction for content computations.

50ms is 3 whole frames, 200ms is 12.5 frames! I thought you were a realtime programmer?

In a visual realtime app, the GC will only be acceptable when it will not interrupt for more than 1ms or so (and I consider that quite generous, I'd be more comfortable with < 500µs). Otherwise you'll lose frames anyway; if your entire world exists within 16ms slices, how can you budget the frame's usual workload around the GC interruption?

And what if the GC interrupts more than once per frame? What if you have very little free memory?