Re: More on garbage collection

From: Bryan Olson (fakeaddress_at_nowhere.org)
Date: 06/11/05 

Date: Sat, 11 Jun 2005 14:10:33 GMT

Nick Maclaren wrote:
> 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.

Sorry if you finds my response offensive, but I am so tired of
these guesses...

Nothing personal intended: I gave enough info for anyone to
Google-up my references. I really did look them up before
posting. I was not just shooting off my mouth; 5%-25% is not
just a number, it is *the* number. If you want to argue that it
is wrong or irrelevant, please cite something so we know you are
not just making it up.

> Please note that this is a theoretically soluble problem.

Noted.

> Try HPC.

O.K. -- I tried. Had to Google it up. "High performance
computing" looked to me to be the best candidate.

> 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.

Noted ... as I said before.

> |> > 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.

Hey, if you want me to back up what I wrote, I'm certainly
ready. If you have verifiable evidence to support your claims,
I'll check it out. If you have bad experiences that color your
personal judgment, well, I sympathize.

> Please note that this has been a known critical requirement for
>
> Please ALSO note that it is a theoretically soluble problem.

Noted. As I said before. More than once. How clever you and I are.

> |> > 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.

Now that is a point.

If you can cite evidence that Lisp programmers (or ML
programmers or such) generally (or even typically) have to take
greater care than others about running out of memory, I'd have
to consider that, and even consider modifying my position.

> 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

Uh, yeah, sure. As well as GC works in Lisp, ML, Java, and C#,
there are still major unrealized optimizations in every one of
them.

> Every time I have investigated systems that people like you claim
> to help with such things,

If you've actually investigated it in this case, or even looked
into it roughly recently, I'd like to hear what you found --
with references, or at least Google-able terms.

> I have found

Please be specific on what you found. I will check it out.

> 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.

"Please note" you say. O.K. Noted ... more than once ... more
than twice. How clever of you to bleat the same non-issue over
and over. Sorry to be so harsh ... well, not all that sorry; I
have a rep 'round these parts. We have *way* too many people who
think they should be the lecturer while others should listen.
The one or two I myself would respect as lecturers don't claim
the position; they just make their case. 

-- 
--Bryan
Loading