Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
: For the record, as much as I would like to be able to use GC in my C++
: programs, I don't think the committee should be looking at optional
: GC.  Complexity of implementation is very high and certainly the
: committee should not require vendors to implement garbage collection.
: Implementing a C++ compiler is too hard already!  Furthermore, I think
: that standardization at this stage would be premature.

Surely it is not too early for the committee to standardize the couple
of extra keywords necessary for safe GC.  This doesn't force
compiler vendors to deal with the complexity of implementing GC
if they don't want to, and assures those vendors that do wish to
that they will not later have to pull their proprietary language
extensions out from under programmers that wrote code using
them.

-------------------------------------------------------------
James Treleaven                        jtreleaven@gallium.com
Gallium Software Inc.

In article <TMB.94Sep21205429@arolla.idiap.ch> tmb@idiap.ch writes:
|The concept of "optional GC" sounds good, but I think most people
|are a little fuzzy on what it means.  What Boehm's GC provides
|seems to be quite reasonable as far as "options" go, and I don't
|see what other functionality people want.

Well, I can tell you what I would want from a GC spec for C++:

I would want the freedom to have an implementation that uses
"state of the art" GC techniques to make the best possible space/time
tradeoffs.  IE I want implementors to be able to pick and choose a GC
implementation from among the entire spectrum of current and future GC
techniques.  I *don't* want someone to make a short-sighted "specification"
of C++ GC for me, someone who decides that today's implementation of
C++ GC is "good enough" for all time.

What is the point of having GC in C++ if it is going to become a second-
rate GC implementation, not able to keep up speedwise with what is
capable in other languages?  When C++ is no longer the faster OOPL,
I, and many others I suspect, will go elsewhere.

People in the C++ world still seem to be viewing GC as optional leak
detection and prevention.  That IMHO is not the role of GC.  Rather,
the role of GC is to permit the implementation of more general and
more efficient algorithms, and to permit moveable objects, such that
working set is optimized.

I am sick to death of "specifications" that force implementation
choice on the implementor.  The idea that a specifier today can
and should spec in order to force the actual implementation for all time is the
ultimate in hubris.

Jim Adcock writes:

    I would want the freedom to have an implementation that uses
    "state of the art" GC techniques to make the best possible
    space/time tradeoffs.  IE I want implementors to be able to pick
    and choose a GC implementation from among the entire spectrum of
    current and future GC techniques.  ...  I am sick to death of
    "specifications" that force implementation choice on the
    implementor.  The idea that a specifier today can and should spec
    in order to force the actual implementation for all time is the
    ultimate in hubris.

I agree 100%.  The Ellis-Detlefs GC proposal (*) is the only serious
*language* proposal I know of.  It was explicitly designed to give
wide latitude to future implementations.  The language proposal
allows for a large range of implementations, including relocating,
compiler-cooperative, and hardware-assisted algorithms.

Are there particular implementation techniques that you think are
precluded by the Ellis-Detlefs proposal?


---------------
(*) Our GC proposal is completely separate from our safe-subset
proposal.  It is covered by sections 1-6 and 8-14 in our paper,
available from parc.xerox.com:/pub/ellis/gc, and was also published in
the April '94 Usenix C++ proceeding.

treleave@prior.com (James Treleaven) writes:

>Surely it is not too early for the committee to standardize the couple
>of extra keywords necessary for safe GC.

Well, maybe, maybe not, but standardizing just keywords doesn't
really buy you much.  Vendors can already use keywords in the
implementation's namespace, eg __gc.  They can provide a header
file gc.h which contains

 #define gc __gc

and require that programs which want to use these keywords need
to #include the header file.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

PGoodwin@ix.netcom.com (Phil Goodwin) writes:

    I could not get an anonomyous ftp to "parc.xerox.com"

Sorry, that should have been parcftp.xerox.com:/pub/ellis/gc.  The
directory contains the full text of the original GC proposal and the
safe-subset proposal.  The April '94 Usenix paper contains just the GC
proposal.

In <36hn1b$la1@news.parc.xerox.com> ellis@parc.xerox.com (John Ellis) writes:

>
>Jim Adcock writes:
>
>    I would want the freedom to have an implementation that uses
>    "state of the art" GC techniques to make the best possible
>    space/time tradeoffs.  IE I want implementors to be able to pick
>    and choose a GC implementation from among the entire spectrum of
>    current and future GC techniques.  ...  I am sick to death of
>    "specifications" that force implementation choice on the
>    implementor.  The idea that a specifier today can and should spec
>    in order to force the actual implementation for all time is the
>    ultimate in hubris.
>
>I agree 100%.  The Ellis-Detlefs GC proposal (*) is the only serious
>*language* proposal I know of.  It was explicitly designed to give
>wide latitude to future implementations.  The language proposal
>allows for a large range of implementations, including relocating,
>compiler-cooperative, and hardware-assisted algorithms.
>
>Are there particular implementation techniques that you think are
>precluded by the Ellis-Detlefs proposal?
>
>
>---------------
>(*) Our GC proposal is completely separate from our safe-subset
>proposal.  It is covered by sections 1-6 and 8-14 in our paper,
>available from parc.xerox.com:/pub/ellis/gc, and was also published in
>the April '94 Usenix C++ proceeding.
>

I could not get an anonomyous ftp to "parc.xerox.com", however, I was
able to to connect to "beta.xerox.com" and I found a copy of your
proposal (dated May 28, 1993) in the specified directory. Is this
the correct site or is the copy I found outdated?

Phil Goodwin                                 oodwin.@Netcom.com

In comp.std.c++ you write:

>For the record, as much as I would like to be able to use GC in my C++
>programs, I don't think the committee should be looking at optional
>GC.  Complexity of implementation is very high and certainly the
>committee should not require vendors to implement garbage collection.
>Implementing a C++ compiler is too hard already!  Furthermore, I think
>that standardization at this stage would be premature.

My impression was that this is a moot point, at least for the initial
standard.  Was I wrong?

A couple of observations:

1. The standard could (and probably should) make an implementation
with the null collector standard conforming.  This makes GC largely
a quality of implementation issue.  The reasons for doing this are that
short-lived programs expecting a GC could still run on such
simplistic implementations.  And, more importantly, the standard presumably
doesn't say anything about space usage anyway, so you can't really
define what it means to have a garbage collector (or a real free
implementation).  It's also not clear to me that the compiler
that generates code to run in your toaster really needs to support
a run-time system with GC.

I'm also in favor of providing the null GC as an option, even if
there is also a real GC implementation.

2. We are giving away a collector that works on nearly all
workstations or PCs.  It needs minimal backend work to make it
guaranteed safe with existing compilers.  But, as John Ellis
has pointes out, if someone shipped it with their existing compiler
and added "lack of GC-safety" to the compiler bug list, I suspect
it would take years until it reached a sufficiently high priority for
someone to actually work on it.

I think point 1 would take care of most compilers for embedded systems
for a while.  Point 2 would take care of workstations and PCs.

There may be other reasons not to standardize a GC facility at this
point.  But I think implementation considerations can be dealt with.

Hans-J. Boehm
(boehm@parc.xerox.com)
Standard disclaimer ...

r-ridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:
>That fact compilers I use give me the option of compiling
>C and C++ (and one even Objective C) doesn't make them the same
>language.

Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>Exactly - so why do you think that adding an additional option "Safe C++"
>would change things?

Great, then if you want a standard encompassing Safe C++, get your own
standard.  Don't try to wedge it into the C++ standard.  Don't even
try to portray as it as simple extension of C++.

       Ross Ridge

--
 l/    Ross Ridge      //
[oo]   The Great HTMU, CSC President   [oo]
-()-         http://csclub.uwaterloo.ca/~rridge/  /()/
 db           +1 519 883 4329                             //

Thomas M. Breuel <tmb@idiap.ch> wrote:
>What matters is that the proposal is compatible with existing draft
>ANSI C++ and that it is very useful.  You probably wouldn't even
>notice if your compiler all of a sudden implemented this proposal.

Of course I would, the compiler would be twice as buggy.

      Ross Ridge

--
 l/    Ross Ridge      //
[oo]   The Great HTMU, CSC President   [oo]
-()-         http://csclub.uwaterloo.ca/~rridge/  /()/
 db           +1 519 883 4329                             //

rridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:

>Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>>Exactly - so why do you think that adding an additional option "Safe C++"
>>would change things?
>
>Great, then if you want a standard encompassing Safe C++, get your own
>standard.  Don't try to wedge it into the C++ standard.

I wasn't trying to do so.

>Don't even try to portray as it as simple extension of C++.

Why not?

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <Cwro3G.CoG@undergrad.math.uwaterloo.ca>
rridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:

|> Thomas M. Breuel <tmb@idiap.ch> wrote:
|> >What matters is that the proposal is compatible with existing draft
|> >ANSI C++ and that it is very useful.  You probably wouldn't even
|> >notice if your compiler all of a sudden implemented this proposal.

|> Of course I would, the compiler would be twice as buggy.

More likely, the implementors would then use the safe C++ part to
reimplement their compiler, and it would be half as buggy.  (In case
you hadn't noticed, current C++ compilers are not particularly none
for their stability.)
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <35rj32$3kc@crl4.crl.com> es@crl.com (Eric Smith) writes:
|My main argument was that you can't really hope to get the advantages
|of garbage collection without getting the disadvantages too, and that
|if you use it at all, anywhere in your program, or in any libraries
|your program uses, it becomes part of your whole program.

Of course.  If I use "sleep" or a busy loop anywhere in my program, or
in any library, it becomes part of my program.  Worse yet, "sleep" or
a busy loop can cause arbitrary delays.  We better get rid of sleeps
and all loop constructs!

|I'm not
|arguing against garbage collection, just that it has costs and that the
|various schemes to try to avoid paying those costs all have problems.

Sorry, but I think you have failed to make a conclusive argument.
Under Ellis and Detlefs proposal, you won't ever invoke the garbage
collector if no part of your program uses collectable memory.  If some
part of your program does use collectable memory, then, of course, the
garbage collector will get invoked.  I don't see the problem.

    Thomas.

In article <35rhem$3gb@crl4.crl.com> es@crl.com (Eric Smith) writes:
|Having garbage collection is like having a live-in housekeeper.  You
|have to decide based not only on the housekeeper's salary, but also on
|whether this person will cause inconvenience, such as using your phone
|when you are expecting a call, or just getting in your way often.  The
|housekeeper could argue that the phone was idle, just like you could
|argue that a garbage collector makes good use of idle time.

You seem to be working under the dangerous assumption that manual
storage management is somehow different from this.  It isn't.  Both
garbage collection and manual storage management have to perform
significant amounts of housekeeping when you invoke "new".  The only
thing that differs is the nature of the housekeeping.

    Thomas.

es@crl.com (Eric Smith) writes:

>David Chase <chase@centerline.com> wrote:
>...
>>Furthermore, it's all optional, so it doesn't affect the code
>>that you have written or will write, if you don't want it to.
>
>That implies that it can't take advantage of the CPU's idle time,
>and will always cause a CPU backlog when it runs.  For that reason,
>good garbage collection can't be completely optional.

Nonsense.

>The reason why completely optional garbage collection can't take
>advantage of the CPU's idle time is that it has no way of knowing
>when the CPU will be idle.  It can try to use the CPU when it seems
>idle, but that might interfere with software that doesn't want any
>garbage collection and doesn't want to be affected by it.

Nonsense.  Garbage collection in the CPU's idle time could VERY easily
be done without impacting on software that didn't request it.  Just mak
it OPTIONAL.  Software which did want this sort of garbage collection
would just have to explicitly request it, e.g. by calling some specific
function at runtime to enable it.

-----------------------------------------------------------------------------

>David Chase <chase@centerline.com> wrote:
>>(Optional) GC is part of what the committee should be looking
>>at, and (optional) safety checking goes hand in hand with GC.

For the record, as much as I would like to be able to use GC in my C++
programs, I don't think the committee should be looking at optional
GC.  Complexity of implementation is very high and certainly the
committee should not require vendors to implement garbage collection.
Implementing a C++ compiler is too hard already!  Furthermore, I think
that standardization at this stage would be premature.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <CwGnnD.6yp@undergrad.math.uwaterloo.ca> r-ridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:
|>Creating the option of using a safe subset does not "turn C++ into safe C".
|
|Yes it does.  That fact compilers I use give me the option of compiling
|C and C++ (and one even Objective C) doesn't make them the same
|language.

It doesn't matter whether Detlefs and Ellis' proposal defines "the
same" or "a different" language as current draft ANSI C++, just like
it didn't matter whether C++ with MI was a different language from C++
without MI.

What matters is that the proposal is compatible with existing draft
ANSI C++ and that it is very useful.  You probably wouldn't even
notice if your compiler all of a sudden implemented this proposal.

    Thomas.

In article <35pesf$chu@wcap.centerline.com>,
David Chase <chase@centerline.com> wrote:
...
>I could write a *normal* memory allocator that chewed up
>idle time coalescing blocks and rearranging free lists,

But each such operation takes time, and you can't predict how much idle
time you have before the CPU will be needed again, so you can't predict
whether such an operation can succeed during idle time, and if it
fails, you might leave memory in an inconsistent state, when it might
be needed during the non-idle time.  So you have to use locks, and that
means you might wind up extending the idle time beyond when it would
really be idle, thus hogging the CPU when it might be needed.

Having garbage collection is like having a live-in housekeeper.  You
have to decide based not only on the housekeeper's salary, but also on
whether this person will cause inconvenience, such as using your phone
when you are expecting a call, or just getting in your way often.  The
housekeeper could argue that the phone was idle, just like you could
argue that a garbage collector makes good use of idle time.

In article <TMB.94Sep21210017@arolla.idiap.ch>,
Thomas M. Breuel <tmb@idiap.ch> wrote:
>In article <35o0jm$3ri@crl4.crl.com> es@crl.com (Eric Smith) writes:
>|Another argument is that you can use real time garbage collection to
>|prevent such interference.  But a lot of the advantage of garbage
>|collection is in its efficiency, and real time garbage collection
>|isn't so efficient.
>
>I find it rather strange that these "real-time" arguments keep coming
>up.  Neither C nor C++ currently have real-time storage allocators;

My argument was not in favor of real time garbage collection.  I
mentioned it as one frequent objection to my argument, so I could
counter it in advance.  I'm not opposed to it either, just pointing out
the tradeoffs.

My main argument was that you can't really hope to get the advantages
of garbage collection without getting the disadvantages too, and that
if you use it at all, anywhere in your program, or in any libraries
your program uses, it becomes part of your whole program.  I'm not
arguing against garbage collection, just that it has costs and that the
various schemes to try to avoid paying those costs all have problems.

Ross Ridge writes:

> Don't waste that C++ committee's time trying to turn C++
> into Safe C++.

This is misleading.  Creating the option of using a safe
subset does not "turn C++ into safe C".  Second, according
to e-mail from one knowledge person:

| The original request to ANSI to establish the committee had
| words to the effect: C++ currently has several weaknesses which
| make it difficult to use on large projects.  The committee
| should investigate extensions to correct these weaknesses, in
| particular templates, exceptions AND GARBAGE COLLECTION.  (On
| the other hand, there is nothing about RTTI and namespaces.)

[The EMPHASIS is not mine, but I like it.]

Safe C++ and garbage collection CAN be treated separately, but
every garbage-collected procedural language that I know of also
includes an "optional" safe subset (though in those languages,
safety and GC are the default cases).  This is where most of the
GC experience comes from -- to adopt (optional) GC without also
adopting (optional) safety checking would be what you might
call a "radical innovation".

Third, the expense of adding safety checking is low, compared
both to the expense of adding GC alone or compared to the
expense of some of the other changes to the language in recent
years. Optional safety checking does not steal any keywords,
even when it is enabled.  It does not require any modifications
to the back-end, and only enough run-time support to tell the
difference between pointers to automatics and other pointers.
The design spelled out in the Ellis-Detlefs proposal is
detailed, meaning that you could use it directly as a guide to
implementing safety -- very little is left to the imagination.

(Optional) GC is part of what the committee should be looking
at, and (optional) safety checking goes hand in hand with GC.
Furthermore, it's all optional, so it doesn't affect the code
that you have written or will write, if you don't want it to.
Last of all, the expense of adding safety checking is low --
this is not a big deal to implementors (GC-safe code generation
is another matter).

yours,

David Chase (speaking for myself)
CenterLine Software

In article <35ne8o$l8m@wcap.centerline.com>,
David Chase <chase@centerline.com> wrote:
...
>(Optional) GC is part of what the committee should be looking
>at, and (optional) safety checking goes hand in hand with GC.
>Furthermore, it's all optional, so it doesn't affect the code
>that you have written or will write, if you don't want it to.
...

That implies that it can't take advantage of the CPU's idle time,
and will always cause a CPU backlog when it runs.  For that reason,
good garbage collection can't be completely optional.

The reason why completely optional garbage collection can't take
advantage of the CPU's idle time is that it has no way of knowing
when the CPU will be idle.  It can try to use the CPU when it seems
idle, but that might interfere with software that doesn't want any
garbage collection and doesn't want to be affected by it.

You can of course argue that there are other sources besides garbage
collection of such interference, but that's just another argument to
not make garbage collection completely optional.

Another argument is that you can use real time garbage collection to
prevent such interference.  But a lot of the advantage of garbage
collection is in its efficiency, and real time garbage collection
isn't so efficient.

Ross Ridge writes:
> Don't waste that C++ committee's time trying to turn C++
> into Safe C++.

David Chase <chase@centerline.com> wrote:
>This is misleading.

Follow this thread back and you'll find someone asking for this.

>Creating the option of using a safe subset does not "turn C++ into safe C".

Yes it does.  That fact compilers I use give me the option of compiling
C and C++ (and one even Objective C) doesn't make them the same
language.

       Ross Ridge

--
 l/    Ross Ridge      //
[oo]   The Great HTMU, CSC President   [oo]
-()-        http://csclub.uwaterloo.ca/u/r-ridge/  /()/
 db           +1 519 883 4329                             //