<div dir="ltr">On 10 April 2013 16:14, Rainer Schuetze <span dir="ltr"><<a href="mailto:r.sagitario@gmx.de" target="_blank">r.sagitario@gmx.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 08.04.2013 05:12, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The GC really needs to be addressed in terms of performance; it can't stop<br>
the world for milliseconds at a time. I'd be happy to give it ~150us every<br>
16ms, but NOT 2ms every 200ms.<br>
Alternatively, some urgency needs to be invested in tools to help<br>
programmers track accidental GC allocations.<br>
</blockquote>
<br>
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:<br>
<br>
1. a thread local flag to disallow and detect GC allocations<br>
2. a flag per thread to specify that the thread should not be paused by the GC during collections.<br>
<br>
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.<br>

</blockquote></div><br></div><div class="gmail_extra" style>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.</div>
</div>