kgwzamboni-news@zambonistiscan.com wrote
> On Tue, 11 Jun 2002 22:45:48 UTC, "Hans Guijt" <hguijt@inter.nl.net>
> wrote:
> > Whenever there is talk about garbage collection I also hear mentions of
> > making it a compiler option. Something worth thinking about is this: is code
> > that requires garbage collection linkable to code that does not require (or
> > worse: may not use, eg. realtime systems) garbage collection?
> >
> > If the answer to this question is "no it cannot" then linking with 3rd-party
> > libraries or compiling in 3rd-party code (ie. code that is not under you
> > direct control) will become a major pain as one author writes with and
> > another without garbage collection.
>
> Multiple storage managment mechanisms need to be supported at the same
> time.  C++ allows this with parameters on the "new" but has left us
> no way to connect the "delete" to the proper storage manager.
> If this were solved somehow, then new(GCManager) could be used
> for those objects.

Conceptually, a GC could intercept all calls to delete, handle the
ones that it allocated in the first place, and pass the rest on to
the normal library delete.

Realistically, that doesn't work. Once you've replaced all forms of
operator delete, there's no longer any way to call the standard
library version -- if there was, then it would be possible for user
code to call it too, and we wouldn't have solved the problem after all.

> Right now I must revert to "C" to do special storage management
> and must be careful to not "delete" the objects, but to call the
> proper deallocator.

The standard guarantees that malloc/free is not implemented in terms
of new/delete, so one way to implement your own memory management is
to call malloc/free. However, this means that a garbage collector
can't collect objects that were created with malloc.

Maybe that's a good thing. Maybe user code should use new/delete for
GC objects, and malloc/free for non-GC objects.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 11 Jun 2002 22:45:48 UTC, "Hans Guijt" <hguijt@inter.nl.net>
wrote:

> "Hans-J. Boehm" <Hans_Boehm@hp.com> schreef in bericht
> news:1178a29f.0206071624.2b9ee163@posting.google.com...
[...]
>
> Whenever there is talk about garbage collection I also hear mentions of
> making it a compiler option. Something worth thinking about is this: is code
> that requires garbage collection linkable to code that does not require (or
> worse: may not use, eg. realtime systems) garbage collection?
>
> If the answer to this question is "no it cannot" then linking with 3rd-party
> libraries or compiling in 3rd-party code (ie. code that is not under you
> direct control) will become a major pain as one author writes with and
> another without garbage collection.
>
>
> Hans Guijt

Multiple storage managment mechanisms need to be supported at the same
time.  C++ allows this with parameters on the "new" but has left us
no way to connect the "delete" to the proper storage manager.
If this were solved somehow, then new(GCManager) could be used
for those objects.
Right now I must revert to "C" to do special storage management
and must be careful to not "delete" the objects, but to call the
proper deallocator.

--
Remove zamboni to reply.
All the above is hearsay and the not quaranteed.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Hans-J. Boehm" <Hans_Boehm@hp.com> schreef in bericht
news:1178a29f.0206071624.2b9ee163@posting.google.com...
> 2) Allow implementations to replace all built-in memory allocation
> mechanisms (malloc, new, STL default allocator) with allocators that
> implicitly garbage collect.  Destructors would be invoked only if
> objects are explicitly deallocated.  Presumably this would be enabled
> by a compiler option.

Whenever there is talk about garbage collection I also hear mentions of
making it a compiler option. Something worth thinking about is this: is code
that requires garbage collection linkable to code that does not require (or
worse: may not use, eg. realtime systems) garbage collection?

If the answer to this question is "no it cannot" then linking with 3rd-party
libraries or compiling in 3rd-party code (ie. code that is not under you
direct control) will become a major pain as one author writes with and
another without garbage collection.


Hans Guijt




---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

We were discussing adding optional garbage collection to
a future version of C++.  Although I personally would like
to look at all the options, we would be foolish not to pay
particular attention to the excellent ready and working
system created by Hans Boehm. This post is particularly
directed at him, but of course anyone else who knows
the answers is encouraged to respond. Whatever the
source, I hope any answers will be of interest to many
of the group.

Which core language changes would help integrate the
Boehm GC system into C++ more efficiently or more easily
than is currently true? Bear in mind the committee would
be very reluctant to accept core language changes that
break any reasonable existing code. I'm thinking more of
changes that would be transparent to the programmer,
such as low-level hooks. For example,

- Knowledge of the location of pointers within objects.

- Hooks into any standard threading system.

As far as I understand it the Boehm GC system can
interoperate with normal dynamic allocation within the
same program although it does have to scan normally
allocated objects for pointers. Presumably, if a program
never allocated any GC objects it would be
straightforward to automatically disable this scanning
and so the GC system, if not used, would be zero cost.
Compiler vendors might wish to have a "No garbage
collection" switch to ensure the GC system wasn't
unintentionally activated due to programmer error.

One last question: what happens when a machine is
low on memory? Is it ever possible that collection could
fail due to lack of memory for internal allocations related
to the collection algorithm itself, or is all this memory
pre-allocated?

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

There are clearly several possible ways to support GC in C++.  These
include:

1) Only allow smart-pointer-based techniques with either a tracing
and/or reference counting collector.  This involves some glitches and
an inherent performance cost.

2) Allow implementations to replace all built-in memory allocation
mechanisms (malloc, new, STL default allocator) with allocators that
implicitly garbage collect.  Destructors would be invoked only if
objects are explicitly deallocated.  Presumably this would be enabled
by a compiler option.

3) Allow selective allocation of garbage-collected memory, e.g. by
explicitly using a different allocator for STL collections, or by
inherting from a "gc" class which provides a nonstandard allocator.

4) Provide a full safe subset of C++ along the lines of the Ellis &
Detlefs proposal.

I think (1) requires no changes to the standard.  But it has other
disadvantagees which have been discussed here.

I would personally like to see (2) supported.  Empirically it's
useful.  Officially sanctioning it would make the Geodesic Systems
Great Circle collector, the Purfy leak detector, and some modes of use
for our collector officially correct.  These are all in fairly
widespread use anyway.

I think the minimum required change to the standard to support this
would be something similar to Bjarne Stroustrup's earlier proposal.
(Google found it at http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/1996/N0932.pdf,
which may may not be a stable reference.)  This essentially allows the
implementation to drop objects that have no recognizable references to
them.

It would be very useful, but less critical than Stroustrup's proposal,
to standardize more of the interface to the optional collector.  In
particular, it would be nice to standardize some way to finalize an
object.  It would also be nice to be able to allocate untraced and/or
uncollectable memory.

An implementation that actually does this may potentially break an
existing application.  Current evidence suggests this will be rare.
And in my mind this is only a theoretical issue, since realistically
no implementations will insist on garbage collection. It does mean
that standard libraries should be prepared to deal with that case.
But I doubt there are any that aren't.

Option (3) has the advantage that it can guarantee to support legacy
libraries.  (With option (2) they usually work.  Guaranteeing that
they work requires turning off GC completely, which is a bit
unpleasant.)

Clearly both options 3 and 4 would require more of a standardization
effort.  I haven't seen a lot of momentum for (4) recently, and Java
may have effectively filled that gap.  For option 3, mechanisms for
allocating collectable and uncollectable memory would also need to be
specified.  Our collector (including the interface originally
implemented by Ellis & Hull) implements one way of doing this.  There
is another proposal in the Ellis & Detlefs paper, though that predates
the STL allocator issues.

Running out of memory:

Our particular implementation is designed to make it possible to
recover from running out of memory to the same extent it is with
malloc/new, i.e. you get a NULL pointer return or exception from the
allocator IF the allocator detects it. This is nontrivial, and
complicates the collector.  Typically this isn't a 100% solution, even
with malloc/free, since you may allocate 99.9999999% of the memory
using new, and then run out of space trying to grow the stack in
response to a nested function call.  I'm not sure there's a practical
way to avoid this in the usual situation in which you have to support
1000+ threads with 2MB+ stacks each in the worst case, but both maxima
are rarely approached.

Hans

"Garry Lancaster" <glancaster@ntlworld.com> wrote in message news:<LwGL8.60913$wd3.9818049@news6-win.server.ntlworld.com>...
> We were discussing adding optional garbage collection to
> a future version of C++.  Although I personally would like
> to look at all the options, we would be foolish not to pay
> particular attention to the excellent ready and working
> system created by Hans Boehm. This post is particularly
> directed at him, but of course anyone else who knows
> the answers is encouraged to respond. Whatever the
> source, I hope any answers will be of interest to many
> of the group.
>
> Which core language changes would help integrate the
> Boehm GC system into C++ more efficiently or more easily
> than is currently true? Bear in mind the committee would
> be very reluctant to accept core language changes that
> break any reasonable existing code. I'm thinking more of
> changes that would be transparent to the programmer,
> such as low-level hooks. For example,
>
> - Knowledge of the location of pointers within objects.
>
> - Hooks into any standard threading system.
>
> As far as I understand it the Boehm GC system can
> interoperate with normal dynamic allocation within the
> same program although it does have to scan normally
> allocated objects for pointers. Presumably, if a program
> never allocated any GC objects it would be
> straightforward to automatically disable this scanning
> and so the GC system, if not used, would be zero cost.
> Compiler vendors might wish to have a "No garbage
> collection" switch to ensure the GC system wasn't
> unintentionally activated due to programmer error.
>
> One last question: what happens when a machine is
> low on memory? Is it ever possible that collection could
> fail due to lack of memory for internal allocations related
> to the collection algorithm itself, or is all this memory
> pre-allocated?
>
> Kind regards
>
> Garry Lancaster
> Codemill Ltd
> Visit our web site at http://www.codemill.net
>
> ---
> [ 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    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hans-J. Boehm:
> There are clearly several possible ways to support GC in C++.  These
> include:
>
> 1) Only allow smart-pointer-based techniques with either a tracing
> and/or reference counting collector.  This involves some glitches and
> an inherent performance cost.
>
> 2) Allow implementations to replace all built-in memory allocation
> mechanisms (malloc, new, STL default allocator) with allocators that
> implicitly garbage collect.  Destructors would be invoked only if
> objects are explicitly deallocated.  Presumably this would be enabled
> by a compiler option.
>
> 3) Allow selective allocation of garbage-collected memory, e.g. by
> explicitly using a different allocator for STL collections, or by
> inherting from a "gc" class which provides a nonstandard allocator.
>
> 4) Provide a full safe subset of C++ along the lines of the Ellis &
> Detlefs proposal.
>
> I think (1) requires no changes to the standard.  But it has other
> disadvantagees which have been discussed here.
>
> I would personally like to see (2) supported.  Empirically it's
> useful.  Officially sanctioning it would make the Geodesic Systems
> Great Circle collector, the Purfy leak detector, and some modes of use
> for our collector officially correct.  These are all in fairly
> widespread use anyway.

The big problem I have with (2) is that it takes over too
much. OK, it's optional in the sense that there is a
big global switch somewhere that you can flick on or
off. But you can't have normal dynamic memory
management and GC-managed allocation sit side
by side in the same program or at least that seems
to be what you are suggesting.

Also, I know your current system requires a bit of function
pointer manipulation to ensure destructors are called at
collection, but I assumed this was more a reflection of your
system's C-based origins rather than a real design
intention and that, if given the opportunity to integrate GC
into the core, destructors would be called as normal.
To just silently not call destructors in some circumstances
is a recipe for disaster.

I think you are too harsh on the smart pointer system:
anything that you can do with raw pointers (and you
have shown that is a great deal as far as an efficient
GC is concerned) can also be done with smart pointers.
Their big advantage is that it becomes easy for both
programmer and compiler/GC system to separate
pointers that the GC system should trace through
from those that are weak pointers or pointers to non-GC
managed memory (this assumes of course that the
latter are permitted). One issue is that you can't
just flip a big switch and have your program start using
GC: you need to program with it in mind from the start
if you wish to use it. Actually, I'm not sure this is a bad
thing.

[snip]

Garry Lancaster:
> > One last question: what happens when a machine is
> > low on memory? Is it ever possible that collection could
> > fail due to lack of memory for internal allocations related
> > to the collection algorithm itself, or is all this memory
> > pre-allocated?

> Our particular implementation is designed to make it possible to
> recover from running out of memory to the same extent it is with
> malloc/new, i.e. you get a NULL pointer return or exception from the
> allocator IF the allocator detects it. This is nontrivial, and
> complicates the collector.  Typically this isn't a 100% solution, even
> with malloc/free, since you may allocate 99.9999999% of the memory
> using new, and then run out of space trying to grow the stack in
> response to a nested function call.  I'm not sure there's a practical
> way to avoid this in the usual situation in which you have to support
> 1000+ threads with 2MB+ stacks each in the worst case, but both maxima
> are rarely approached.

I actually asked about memory usage at *collection* not during
allocation. My concern is that collection may require dynamically
allocated memory to proceed, so you could end up in a catch-22
situation of having plenty of garbage ready to collect but not have
enough free memory to run the collection.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1178a29f.0206071624.2b9ee163@posting.google.com>,
Hans_Boehm@hp.com (Hans-J. Boehm) wrote:
>1) Only allow smart-pointer-based techniques with either a tracing
>and/or reference counting collector.  This involves some glitches and
>an inherent performance cost.

>2) Allow implementations to replace all built-in memory allocation
>mechanisms (malloc, new, STL default allocator) with allocators that
>implicitly garbage collect.  Destructors would be invoked only if
>objects are explicitly deallocated.  Presumably this would be enabled
>by a compiler option.

>3) Allow selective allocation of garbage-collected memory, e.g. by
>explicitly using a different allocator for STL collections, or by
>inherting from a "gc" class which provides a nonstandard allocator.
...
>I would personally like to see (2) supported.  Empirically it's
>useful.

When implementing a polymorphic with a lot objects calling each other,
used for example when implementing functional and dynamic languages, then
it is not enough with (2) above, to know that the compiler may or may not,
by a special option, do GC, because the code won't be portable: Therefore,
one must at least have a C++ option telling whether conservative GC is
taking place.

I am now using a ref count, that is (1) above, and others seem to do that
in small projects, unless they are implementing a full functional or
dynamic language, in which case they probably switch C anyway, writing out
all registers explicitly in code, because C++ does not help much anyway.
-- And it is sorry that C++ does not help you much here.

But the (1) option is not very convenient either, because one still has to
keep track of various things (which I do not immediately recall) in order
to get it right.

Therefore, I land at having at least (3) above: One should be able to have
at least a GC hierarchy. How the allocation of other objects are handled
under such circumstances it less important (use GC or other method) is
less important: The main objective is to ensure that the GC is being used
in this particular hierarchy.

Also note that when implementing a polymorphic hierarchy, it is common to
have at least two GC's, for "unboxed" (no extra pointer) for small objects
of maximum fixed size, and "boxed" elements (using an extra pointer for
mutating variable into object of another size). Also, if the compiler has
an option, as in (2) above, for engaging the GC, what happens if one loads
a library in which this option has not been set?

-- So then one lands on at least (3) above, with multiple GC's, somehow
coordinated if needed for the implementation.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

    I would argue that under no circumstances should an asynchronous
garbage collector call a destructor.  Garbage collectors can call
finalizers, but a syntatical distinction should be made
between the two if garbage collection is put in the language.
It needs to be clear in the code which approach is being used.

    If garbage collection is supported in the language,
objects with destructors should not be eligible for garbage
collection, and suitable compile-time errors should be reported.
Note that it's possible to create this problem directly,
via inheritance, and via inclusion of one object in another.

    Mixing of GC and non-GC objects needs to be worked out
very carefully.  One big compiler switch isn't the answer.

    John Nagle
    Animats

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article
<remove.haberg-0806021343310001@du131-226.ppp.su-anst.tninet.se>,
remove.haberg@matematik.su.se (Hans Aberg) wrote:

>In article <1178a29f.0206071624.2b9ee163@posting.google.com>,
>Hans_Boehm@hp.com (Hans-J. Boehm) wrote:
...
>>2) Allow implementations to replace all built-in memory allocation
>>mechanisms (malloc, new, STL default allocator) with allocators that
>>implicitly garbage collect.
 ...

>>3) Allow selective allocation of garbage-collected memory, locator. ...

>Also note that when implementing a polymorphic hierarchy, it is common to
>have at least two GC's, for "unboxed" (no extra pointer) for small objects
>of maximum fixed size, and "boxed" elements (using an extra pointer for
>mutating variable into object of another size).
...
>-- So then one lands on at least (3) above, with multiple GC's, somehow
>coordinated if needed for the implementation.

Actually, this use of unboxed and boxed elements is in reality just a form
of optimization. So if one can make C++ or a C++ library handling it, that
would be the best solution. -- Because then those specializing on GC's and
their optimizations can concentrate on doing only that, and those writing
programs with dynamic structures can concentrate on that without having to
worry about the GC implementation details.

But one would still have to consider such uses, in order to make user that
the wanted optimizations are achievable.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3D043690.7050905@animats.com>, John Nagle <nagle@animats.com> wrote:

>    I would argue that under no circumstances should an asynchronous
>garbage collector call a destructor.  Garbage collectors can call
>finalizers, but a syntatical distinction should be made
>between the two if garbage collection is put in the language.
>It needs to be clear in the code which approach is being used.

I got the impression that a "destructor" is what is called when the object
according to its origin in the C++ syntax become obsolete. By contrast, a
"finalizer" should be what is called right before the object is removed
during GC time.

It seems me that if C++ should be extended to support GC implementations
somehow, C++ needs to have both, with the possibility of statically
optimize them away if not needed: I recall I saw some posts that having
both might be inefficient.

Clearly, if the destructors are doing merely memory management, then with
a GC in place, destructors should not be needed. The finalizers might be
needed in the implementation of the GC (assuming that the GC is not a part
of the C++ language, but C++ just supports the implementation of GC's in
libraries.) (And if my impressions of the topic are correct... :-) )

>    If garbage collection is supported in the language,
>objects with destructors should not be eligible for garbage
>collection, and suitable compile-time errors should be reported.
>Note that it's possible to create this problem directly,
>via inheritance, and via inclusion of one object in another.

This problem is complicated by the fact that a destructor may not
necessarily only do memory management: One may use the destructor as a
signal that the object is obsolete, but wanting to let the memory
management because say it is more efficient.

>    Mixing of GC and non-GC objects needs to be worked out
>very carefully.  One big compiler switch isn't the answer.

This seems to be the case: I figure that even if one admits a GC, non-GC
dynamic objects will exist via libraries, etc. (which may then not have
the sources available, or may be an external linked C library or
something).

So mixing must be permitted and be worked out in detail.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle:
>     I would argue that under no circumstances should an asynchronous
> garbage collector call a destructor.  Garbage collectors can call
> finalizers, but a syntatical distinction should be made
> between the two if garbage collection is put in the language.
> It needs to be clear in the code which approach is being used.

What's your rationale?

>     If garbage collection is supported in the language,
> objects with destructors should not be eligible for garbage
> collection, and suitable compile-time errors should be reported.
> Note that it's possible to create this problem directly,
> via inheritance, and via inclusion of one object in another.

So you would not permit vectors or basic_strings to be
garbage collected, for example.

>     Mixing of GC and non-GC objects needs to be worked out
> very carefully.  One big compiler switch isn't the answer.

I would certainly prefer something more flexible.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]