Byron Hale <[EMAIL PROTECTED]> wrote,
> At 05:21 AM 8/11/2000 +0100, you wrote:
> >On Fri 11 Aug, Byron Hale wrote:
> > > Also, garbage collection is unlikely to satisfy any need
> > > for automatic memory management in real-time systems for the foreseeable
> > > future because an extra thread on a single processor is still
> > > non-deterministic.
> >
> >I'm not sure this is true, doesn't it depend on the scheduling strategy?
> >I've written a lot of code for single and multiple processor DSP systems,
> >and typically have multiple threads (on 1 processor).
> >But they are still entirely deterministic.
>
> I don't mean that threads are non-deterministic, but that the execution
> time of a GC thread seems to be non-deterministic. Large collections need
> more time than small ones and the time required is some function of the
> store to be collected, is it not?
Not necessarily. In a copying collector, it can be size of
live portion of the store only. Ie, by guaranteeing that
your program never hangs on to too much data, you can put an
upper bound on the GC time.[1]
> ML-Kit has implemented some work on compile-time memory management using
> regions. I wonder if that might not be more practical than garbage
> collection, in real-time systems.
Realtime Java uses a kind of explicitly handled regions (not
automatically inferred as in the ML implementation).
However, the way they integrated the feature is IMHO very
awkward.
Manuel
[1] Guaranteeing that your program doesn't hang on to too
much data is not easy, but you essentially have to do
that also when you do explicit memory management.
