[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Garbage Collector Cost
- From: Paul Hudson <phudson@...>
- Date: Wed, 27 Oct 2010 10:37:09 +0100
Every hard real time system has some latency. It depends on the
requirement if it works for your situation. If it has an upper bound
it is hard real time in my view
On 27/10/2010, Rob Kendrick <email@example.com> wrote:
> On Wed, Oct 27, 2010 at 12:10:35PM +0300, Juris Kalnins wrote:
>> On Wed, 27 Oct 2010 11:58:16 +0300, Rob Kendrick <firstname.lastname@example.org> wrote:
>> >On Wed, Oct 27, 2010 at 08:39:58AM +0300, Juris Kalnins wrote:
>> >>If the script is short lived, and turning GC completely off is
>> >>an acceptable option, it's the most predictable way. It is
>> >>possible then to
>> >>run full GC manually at known times.
>> >How is it possible to know how long the GC will take, even if you run it
>> >at known times?
>> If you know how much allocated data there is, and you know that collection
>> will not be delayed (e.g. because of __gc finalizers), then you have a
>> known upper bound on mark&sweep time.
> And what if this upper-limit on time is greater than your hard real-time
> will allow? ie, you get a break in your work, so you decide to do some
> GC, but it's going to take longer than you have time available before
> you need to do work again. What do you do? Put it off until next time?
> What if the same happens again?
> Basically, the only solutions are infinite memory (turn off GC) or a
> very fruity GC system using content-addressable memory (which nobody
Sent from my mobile device