On 10.04.2013 08:26, Manu wrote:
On 10 April 2013 16:14, Rainer Schuetze <r.sagita...@gmx.de> wrote:
On 08.04.2013 05:12, Manu wrote:
The GC really needs to be addressed in terms of performance; it can't stop
the world for milliseconds at a time. I'd be happy to give it ~150us every
16ms, but NOT 2ms every 200ms.
Alternatively, some urgency needs to be invested in tools to help
programmers track accidental GC allocations.
I'm not sure if these have been proposed already in this long thread, but
2 very small patches could help a lot for realtime applications:
1. a thread local flag to disallow and detect GC allocations
2. a flag per thread to specify that the thread should not be paused by
the GC during collections.
The latter would then put the responsibility on the programmer to ensure
that no references are mutated in the non-pausing thread that don't exist
anywhere else (to avoid the collection of objects used in the realtime
thread). As anything in a realtime thread usually has to be pre-allocated
anyway, that doesn't put a lot more constraints on it but to ensure having
references to the pre-allocated data in other threads or global state.
It's all rather useless without some powerful tools for tracking down
leaks, and unintended allocations though. There will surely be bugs with
this idea, and finding them will be a nightmare.
It needs some kind of manual ownership handling that's more or less
similar as what you do in C++ right now. IMO it allows to workaround
some bad consequences due to the mere existence of the GC without giving
up its benefits in other threads.
I don't expect a GC any time soon with pause times acceptable for real
time tasks. I'd be happy if they were acceptable for standard
interactive programs (hopefully the concurrent version can be ported to
Windows aswell).
