I'm looking forward to some sort of flag or option to turn on the
incremental GC, and trying to understand a bit more about the design space.
My naive thought process goes something like this:
1. The total time to collect garbage probably grows with number of
objects and total size to be freed (though maybe size doesn't matter much
here?)
2. An incremental GC will collect until it runs out of time, then hand
control back to the application until it's time to run again
3. It seems like there's a rate of garbage generation where you're
building up garbage faster than the GC can collect it without missing its
deadline
4. It seems like if you stay below this rate you can consider your
maximum pause time to be bounded and memory won't be leaking. We hold hands
and sing songs.
5. So the issue is what to do when you're above that rate. Either you:
1. make sure memory consumption doesn't grow indefinitely by having
some heuristic for when the GC decides to give up on the deadline, OR
2. make sure the GC never violates its deadline and run the risk of
running out of memory
Are there other options besides those two?
I would definitely welcome an actual hard-realtime bounded-pause-time GC,
but it also seems valuable (and possibly more feasible) to have a GC where
the pause time is bounded with caveats and more careful programming. I'm
not sure whether this qualifies as *hard *realtime, though it seems like it
might if you can make those guarantees about your application code.
It's also worth mentioning for other folks interested in latency that that
JIT compilation is a killer as well, so you need to guarantee that you're
pre-compiled all the possible methods that might get dispatched to.
peace,
s
On Mon, Sep 29, 2014 at 4:25 PM, Stefan Karpinski <[email protected]>
wrote:
> On Mon, Sep 29, 2014 at 4:21 PM, Uwe Fechner <[email protected]>
> wrote:
>
>> Jeff Bezanson suggested in the following discussion (
>> https://github.com/JuliaLang/julia/pull/5227 ):
>> > It would be great to have the option to build with a low-pause GC for
>> users who might want that.
>>
>> This is exactly what I am looking for: To have two different garbage
>> collectors for Julia, a fast collector for non-real-time applications and a
>> low-latency GC
>> for real-time applications. Uwe
>>
>
> Yeah, that would be great.
>
