>>>>> "bd" == BDall <·····@creo.bc.ca> writes:
bd> There have been numerous postings about the speed of GC versus
bd> 'manual' memory management. One target audience which I feel has
bd> been missed is the real-time programmer ...
Right. Real time is crucial to about 1/4 of the programming we do. And it is
the most difficult 1/4. It is the area where having a good language like lisp
or dylan would pay off the most, if we could get acceptable deterministic
behavior from a GC.
I think there are results on bounded time GC algorithms. Anyone?
Also, this stuff in the Java pages about GC in a low priority thread sounds
interesting. Anyone know anything about it? It doesn't sound very reasonable
to me, but what do I know?
Don
In <····················@alumni.ndc.com> ······@ndc.com (D. Erway) writes:
>Right. Real time is crucial to about 1/4 of the programming we do. And it is
>the most difficult 1/4. It is the area where having a good language like lisp
>or dylan would pay off the most, if we could get acceptable deterministic
>behavior from a GC.
>I think there are results on bounded time GC algorithms. Anyone?
There are many bounded-time GC algorithms. In general, the incremental
overheads associated with these are very high. And the tighter you manage
to bound the worst-case latency, the higher the incremental overheads.
Overheads are reflected both in run-time throughput (read and write barriers
add code and decrease caching/paging efficiency) and in memory utilization
(some of the most deterministic real-time garbage collectors require
considerably more memory than typical non-real-time garbage collectors).
The biggest challenge of real-time garbage collection is to bound worst-case
response times without sacrificing performance or memory utilization
efficiency.
>Also, this stuff in the Java pages about GC in a low priority thread sounds
>interesting. Anyone know anything about it? It doesn't sound very reasonable
>to me, but what do I know?
I view this as an interim hack, at least insofar as real-time performance
is concerned. There are many situations in which the low-priority GC
thread will become starved for CPU time. When this happens, memory is
not recycled quickly enough and the application threads are unable to
allocate memory. Sun's current solution (as reported to me by a member
of Sun's Java team) is to stop-the-world and finish garbage collection
whenever this problem arises. Real-time engineers call this "priority
inversion" in the sense that a relatively low priority process may
trigger a full stop-the-world garbage collection, forcing all higher
priority tasks to block until this low-priority task's need for memory
has been satisfied. We are implementing a different semantics for our
real-time Java environment.
--
Kelvin Nilsen, Research Scientist
151 ASC II, CATD voice: (515) 294-5143
Iowa State University fax: (515) 294-9519
Ames, IA 50011 internet: ······@iastate.edu
In article <····················@alumni.ndc.com>, ······@ndc.com (D.
Erway) wrote:
> >>>>> "bd" == BDall <·····@creo.bc.ca> writes:
>
> bd> There have been numerous postings about the speed of GC versus
> bd> 'manual' memory management. One target audience which I feel has
> bd> been missed is the real-time programmer ...
>
> Right. Real time is crucial to about 1/4 of the programming we do. And it is
> the most difficult 1/4. It is the area where having a good language like lisp
> or dylan would pay off the most, if we could get acceptable deterministic
> behavior from a GC.
>
> I think there are results on bounded time GC algorithms. Anyone?
You might check out the stuff in my ftp/www directory, and also the
stuff at ftp.cs.utexas.edu in /pub/garbage.
> Also, this stuff in the Java pages about GC in a low priority thread sounds
> interesting. Anyone know anything about it? It doesn't sound very reasonable
> to me, but what do I know?
The latest IWMM'95 (International Workshop on Memory Management, 1995,
Springer-Verlag (c) 1995) has several papers on real-time gc.
--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
······@ndc.com (D. Erway) writes:
>>>>>> "bd" == BDall <·····@creo.bc.ca> writes:
> bd> There have been numerous postings about the speed of GC versus
> bd> 'manual' memory management. One target audience which I feel has
> bd> been missed is the real-time programmer ...
>Right. Real time is crucial to about 1/4 of the programming we do. And it is
>the most difficult 1/4. It is the area where having a good language like lisp
>or dylan would pay off the most, if we could get acceptable deterministic
>behavior from a GC.
>I think there are results on bounded time GC algorithms. Anyone?
There are several GC algorithms that give real-time bounds. Henry Baker is
the inventor of the two most commonly cited ones. There
is typically some additional overhead associated with implementations that
provide good execution time bounds. But it would be nice to provide such
a collector as an option.
As you point out, there are some applications that require real-time GC.
But I think this is an issue that's often perceived to be more important
than it actually is. Both our collector and the Geodesic Systems collector
for C/C++ provide VM synchronized incremental GC. This isn't a hard real-time
collector, but it typically gives you response comparable to a VM system,
and better than most networks. Interestingly, my experience has been that
people rarely turn on incremental collection. In a recent talk by people
from Geodesic Systems, it was pointed out that none of their customers had
turned it on yet. Nonetheless, I suspect they would have a harder sales
job if they didn't provide an incremental GC option.
There also seem to be some applications that require hard real-time
bounds, but can tolerate less than a full real-time collector. Some
collectors can be aborted quickly, if you're willing to discard most
of the work they did so far. Sometimes it's possible to arrange for
the real-time components to run independently of the GC.
Hans-J. Boehm
(·····@parc.xerox.com)
Standard disclaimer ...