dak <pierreba@poster.cae.ca> writes:

>[Moderator's note: this thread has migrated from comp.lang.c++.moderated.
>The "-mod" quoted below is one of the moderators of that newsgroup,
>not one of the moderators of comp.std.c++.  -fjh]

>lars.farm@nts.mh.se (Lars Farm) wrote:

>[snip]

>> I'm not on the committee. I'm sure you know the facts better than I do.
>> What I do know is that John Ellis (the author of one GC proposal) wrote
>> in c.std.c++ that his proposal was never formally put to the committee
>> because he considered it without chance of beeing accepted and that
>> Bjarne Stroustrup once answered me in c.std.c++ that there never was a
>> formal proposal made, and that it's too late now (this was quite a while
>> ago). This doesn't mean it was never discussed, but that was the
>> impression I got from those two replies. Let me rephrase that last
>> statement in a way that hopefully doesn't offend anyone. Here goes: - "I
>> think that it is a pity GC was not included in the language."
>>
>> { Strictly speaking, Bjarne (rightly, IMO), isn't keen on *any* feature
>>   that has a size/space overhead WHEN IT IS NOT USED. GC algos are very
>>   clever today, but there *is* an overhead.  I think BS really wants GC
>>   to be standardised in a ANSI/ISO C++ *revision*, so it gets standardised,
>>   but doesn't hold up the ship, or is manditory for a ANSI C++ compiler.
>>   See "The Design and evolution of C++" -mod }

> [more snip]

Wait. I am under the impression that for anything that can be
standardized, it has to be in use.

This is certainly true for a standard that I used to track. I
believe the same holds for C++. Or is it?

If so, that leaves room for variants of C++ with GC. Java perhaps?
--
e-mail: fwai@armltd.co.uk
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

> >> { Strictly speaking, Bjarne (rightly, IMO), isn't keen on *any* feature
> >>   that has a size/space overhead WHEN IT IS NOT USED. GC algos are very
> >>   clever today, but there *is* an overhead.

None that I've ever been able to measure, WHEN IT IS NOT USED.
The Boehm-Weiser collector, NINE YEARS AGO, was perfectly capable
of being run as if it were malloc and free, with *LESS* time or space
overhead than the implementations of malloc and free popular at the time.
It still can be used in this fashion, and is still competitive when used
as an implementation of malloc/free.  When I write a version of malloc
and free that I intend to be space- and time-efficient, I use essentially
the same data structures that Boehm uses in his garbage collector.

In article p5s@sis.armltd.co.uk, fwai@armltd.co.uk (Francis Wai) writes:
> Wait. I am under the impression that for anything that can be
> standardized, it has to be in use.

GC with C++ has been in use for years now.  Except for my general
aversion to C++, I would have been one of those users.  I've used GC
with C on and off since 1987.  Though there are theoretical problems
posed by optimizers (which could be repaired, given a little work, if
GC were in the standard -- if anyone wants help doing this, I'm ready
to give small amounts of advice, for free (1) ), I have *NEVER* (emphasis
enough?) observed such a problem in the field (2).

In contrast, consider the general bugginess and inconsistency of C++
compilers (3), and the apparent tendency of the committee to specify
things that have never been implemented, or have only been implemented
as toys, or only tested by their implementors.  This is made somewhat
worse because of the way that all the features seem to interact; even
if a feature has been well-tested in isolation, it may not have been
well-tested in combination with other features.

Do note that this seems contrary to other statements I've made about
GC in C++ -- namely, that no vendor has signed up to support it, so
it shouldn't be considered for standardization.  This is still true.
On the other hand, many of the other things that vendors have signed
up to support were insufficiently proven before being incorporated
into the standard, which may help explain why the "support" is so often
sadly lacking.  That is, if I argue on the grounds of "the world as it
ought to be", GC would not be accepted in the to C++ standard, but C++
would look nothing like it does today.  By the low standards that appear
to hold for C++ and its standard, GC could certainly be incorporated
into the standard -- it is much more proven than many other things
that have made it in.

(1) Hans and I have been working on lowering the cost of good GC-safe
optimization for years.  The crucial things to watch out for are "stupid
code-generation tricks" (the cause of the two observed in-the-field
faults), and to employ reassociation to shuffle pointers-to-GC-heap
out of addressing expressions (using the same stunts that people from
Rice use with loop nesting depth to help generate more code-improvement
opportunities -- see papers by Keith Cooper and/or Preston Briggs).
Some care has to be taken with register allocation and scheduling,
depending on the structure of the compiler.  There are also various
simple transformations that can be applied at the source, AST, or IL
level that make it extremely unlikely that an optimizer will "break" a
garbage collector, and these appear to have low cost, at least according
to a paper Hans published in the 1996 PLDI.

(2) I've induced it "in the lab" by writing pathological code intended
to cause the problem, as long ago as 1988.  Hans Boehm has observed the
problem in code produced by two different compilers (one for Power/AIX,
one for the Acorn Risc Machine), but the triggering condition (very large
structures with individual members at large offsets, multiple threads)
can be relatively easily described.

(3) In one project that I know of, the developers have given up
attempting to reconcile the differences between the latest Sun, HP, and
IBM compilers, and have decided to live with g++.  It's buggy, but not
any worse than the others, and it's only one set of bugs to deal with,
not three.

speaking for myself,

David Chase



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

[Moderator's note: this thread has migrated from comp.lang.c++.moderated.
The "-mod" quoted below is one of the moderators of that newsgroup,
not one of the moderators of comp.std.c++.  -fjh]

lars.farm@nts.mh.se (Lars Farm) wrote:

[snip]

> I'm not on the committee. I'm sure you know the facts better than I do.
> What I do know is that John Ellis (the author of one GC proposal) wrote
> in c.std.c++ that his proposal was never formally put to the committee
> because he considered it without chance of beeing accepted and that
> Bjarne Stroustrup once answered me in c.std.c++ that there never was a
> formal proposal made, and that it's too late now (this was quite a while
> ago). This doesn't mean it was never discussed, but that was the
> impression I got from those two replies. Let me rephrase that last
> statement in a way that hopefully doesn't offend anyone. Here goes: - "I
> think that it is a pity GC was not included in the language."
>
> { Strictly speaking, Bjarne (rightly, IMO), isn't keen on *any* feature
>   that has a size/space overhead WHEN IT IS NOT USED. GC algos are very
>   clever today, but there *is* an overhead.  I think BS really wants GC
>   to be standardised in a ANSI/ISO C++ *revision*, so it gets standardised,
>   but doesn't hold up the ship, or is manditory for a ANSI C++ compiler.
>   See "The Design and evolution of C++" -mod }

First, GC and non-GC modules can be intermixed. It's easy to have the
delete calls mark the objects as already GC'ed. Second, it is also easy
not to have any penalty if not used: simply put the garbage collector in
a library and have a similar restriction to that of typeinfo: the garbage
collector is only used if any module include a special header (say gc.h).
The implementation only has to declare an external variable in the header
which brings in the collector. Thus the argument doesn't hold.

The only valid arguments are lateness and complexity to implement on ALL
platforms (although you could have a last resort implementation in which
the collector simply never runs!).
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]