Re: More on garbage collection

• Previous message: Nick Maclaren: "Re: More on garbage"
• In reply to: Bryan Olson: "Re: More on garbage collection"
• Next in thread: Bryan Olson: "Re: More on garbage collection"
• Reply: Bryan Olson: "Re: More on garbage collection"
• Reply: Stefan Monnier: "Re: More on garbage collection"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: 11 Jun 2005 10:12:01 GMT

In article <mqwqe.2249$bv7.113@newssvr21.news.prodigy.com>,
Bryan Olson <fakeaddress@nowhere.org> writes:
|> Nick Maclaren wrote:
|> > Start with anything where memory access is performance critical
|> > (and I mean critical, not important). Such as much of HPC. It
|> > is quite unacceptable to be inflicted with an uncontrollable
|> > factor of 2-5 slowdown (and that is typical), both because of
|> > its value and because it blocks tuning. Modern systems are bad
|> > enough, but adding garbage collection is a disaster.
|>
|> Modern systems are way ahead of that. Garbage collection got
|> much faster in the mid 1980's with the generational
|> optimization, and the overhead is now typically 5%-25%. (Numbers
|> from a couple good surveys of GC available on the net, one by
|> Paul R. Wilson and another by Min Zhong.)

Such methods typically have a worst-case factor of two loss on
space utilisation. Many applications cannot tolerate that.

And I was not talking about the factor of 2-5 being because of
the overheads of the garbage collector, but because of its effects
on the memory layout. The time spent in memory management may be
0.001% and the slowdown may still be 2-5 times.

Please note that this is a theoretically soluble problem.

|> > Then move on to any requirement which is storage-limited and
|> > where good user-comprehensible, diagnostics are essential, or
|> > where the requirements are such that only some techniques will
|> > work. All garbage collection languages that I know of fail
|> > dismally on this one.
|>
|> I can't tell exactly what cases you are talking about. Certainly
|> there exists low-level software for which GC is inappropriate.

Try HPC. Try portable real-time or high-RAS code - i.e. where it
can rely only on what is specified in the language, and not on
implementation-dependent properties.

Please note that this is a theoretically soluble problem.

|> > A variation of that is anything high-security (which, inter alia,
|> > means that an uncontrolled denial of service is unacceptable).
|>
|> Garbage collection, in type-safe languages that can really
|> support it, is a huge win for security; manual storage
|> management is notoriously error-prone. The denial-of-service
|> problem is from so-called "conservative garbage collectors" for
|> type-weak languages such as C.

Oh, really? Please name a language where I can specify a priority
on allocations so that, WHEN I run out of space (and it WILL happen),
I can control the error recovery. And please note that this MUST
include clear statements of exactly what constructions I may use
in (a) critical code and (b) error recovery code.

Please note that this has been a known critical requirement for
very high availability systems for 40+ years.

Please ALSO note that it is a theoretically soluble problem.

|> > This adds the space constraint to the time constraint needed by
|> > hard real-time codes.
|> >
|> > And now take a similar application where its failure mode is
|> > likely to be the creation of an immensely large and complex
|> > set of data structures. An automatic garbage collector will
|> > often turn a hard debugging exercise into an infeasible one.
|>
|> Users of languages with GC disagree. For decades Lisp
|> programmers have been building data structures at least as
|> complex as anyone else's.

I am aware of that. However, all of them that I have ever heard
of take great care that they don't get near the limits, either of
resource availability or of algorithmic/logical misbehaviour.
Those are not always feasible to avoid, and it is dealing with
those hard cases that I am referring to.

Take a typical (and I do mean typical) case, where your application
is LIKELY to run out of resources after an arbitrary, long time and
it is infeasible either to interact with it or a debugger or take
a dump. Very common in HPC. Your requirement is to detect such
failures, and diagnose them automatically in the program, separating
ones where the algorithm or logic has failed from ones where the
problem is simply too large to handle. In the latter case, you
need to classify the resource use.

Every time I have investigated systems that people like you claim
to help with such things, I have found that they provide no tools
that help worth a damn. The closest I have seen was a crude draft
specification of (inadequate) extra facilities for possible
implementation at some later date.

Please note that it is a theoretically soluble problem.

Regards,
Nick Maclaren.

• Previous message: Nick Maclaren: "Re: More on garbage"
• In reply to: Bryan Olson: "Re: More on garbage collection"
• Next in thread: Bryan Olson: "Re: More on garbage collection"
• Reply: Bryan Olson: "Re: More on garbage collection"
• Reply: Stefan Monnier: "Re: More on garbage collection"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]