SGCL - Garbage Collector for C++

[peter koch]

If you think you can recurse a 1000000 times in C or in C++,
you've got another think coming.  It just won't work, at least
with the implementations I've got access to.

Well... one million times should not be a problem. This only requires
a stack of the order of 16 megabytes, which really should not be a
problem one any desktop computer today. Multiply by a factor of 100
and you would get problems. One million should be okay if you are
aware of the problem.
But in reality: Who would ever in practice need to recurse so deeply?
Even with quite complicated datastructures, I would be surprised if
even a recursion depth of 10000 would occur.

/Peter

/Peter

 

[Pete Becker]

Excellent. What about std::hash<type_info>?

Not there yet. <g> I think it's a better solution than adding a
hash_code() member function to type_info, which could lead to binary
incompatibilities.

 

[Jon Harrop]

If you think you can recurse a 1000000 times in C or in C++,
you've got another think coming. It just won't work, at least
with the implementations I've got access to.

Exactly. That is a shortcoming of those languages and does not reflect upon
recursion.

 

[Jon Harrop]

SGCL is precise, parallel garbage collection library for C++ (at this time
for Windows 32/64 only). SGCL is free software published under University
of Illinois/NCSA Open Source License.

Get it at:
http://sourceforge.net/projects/sgcl/

Regards
Sebastian Nibisz

I can't find any useful information about this project, e.g. what kind of
GC, what are its properties, could it be used in Mono...

 

[Jerry Coffin]

I think we must follow the approach of C++/CLI (if not adopting it):
Separation of native types and new "managed" types, both having their
own kinds of pointers, and both being able to be intermixed.

IMO, it would be better to forego garbage collection completely -- it
doesn't provide (anywhere close to) enough utility to justify this kind
of brain damage.

 

[Jeff Schwab]

Exactly. That is a shortcoming of those languages and does not reflect upon
recursion.

It's not a short-coming of the languages, it's a QoI issue. Functional
languages translate such deep recursion into loops, because they have
to. Procedural languages provide looping constructs directly, so there
is not a compelling reason to perform such an optimization. If
recursion ever becomes a hyper-fashionable alternative to looping,
subsequent procedural language implementations likely will offer
guarantees about what sorts of recursion will be translated to loops.
In today's environment, though, as Peter Koch said, there is rarely (if
ever) a need for such deep recursion, anyway.

 

[peter koch]

Exactly. That is a shortcoming of those languages and does not reflect upon
recursion.

 

[peter koch]

Exactly. That is a shortcoming of those languages and does not reflect upon
recursion.

What do You mean? Do yo mean the inability to change a recursion to a
loop or the inability to have a large stack?

If it is the first case, then you're wrong: the loop in question could
not be reduced to a loop. If it the other case, youre also wrong
because there is nothing that demands that only a small stack should
be used.

/Peter

 

[Sebastian Nibisz]

I can't find any useful information about this project, e.g. what kind of

GC, what are its properties, could it be used in Mono...

I am creating the project alone and I didn't have time to deal with
documentation.

SGCL is implementing concurrent garbage collector. Garbage collecting is
executed in the separate thread and doesn't require the synchronization with
different threads of the application.

rgds
Sebastian Nibisz

 

[Jon Harrop]

I am creating the project alone and I didn't have time to deal with
documentation.

SGCL is implementing concurrent garbage collector. Garbage collecting is
executed in the separate thread and doesn't require the synchronization
with different threads of the application.

Hi Sebastian,

Thank you for replying. I believe a concurrent garbage collector is
something of huge important that the open source world needs in order to
start catching up with .NET.

I appreciate that it takes a lot of time to write documentation and a
website covering a project like this but I would be very grateful if you
could elaborate on the exact algorithm or approach used and whether or not
you think this would be suitable for something like Mono. How does your GC
compare with the one in .NET, for example?

 

[Jerry Coffin]

[ ... ]

You seem to be expecting a lot more from garbage collection than
I'm asking. I don't want to change the basic paradigms of C++.

I don't particularly want to change any paradigms -- but I think if
we're going to pay a price (e.g. taking some behavior that is now
defined and making it undefined) we should get something in return.
Specifically, I think we should be able to depend on _something_ that we
can't now, such as being sure that an allocation will never fail due to
heap fragmentation.

I want garbage collection for two fairly simple reasons:

[ ... ]

Simple, conservative collectors, such as the Boehm collector,
are largely sufficient for this.

IMO, these carry (at least) 80% of the cost of supporting a collector
that can compact the heap, while providing only (something like) 20% of
the benefit. Increasing the cost by an (almost) insubstantial margin
increases the benefit by a _much_ larger margin. In short, in a cost vs.
benefit analysis, I see no reasonable support for the Boehm-Demers-
Weiser collector, or anything very similar.

Don't get me wrong: I don't think the standard can or should _mandate_
other collector strategies -- but I think it would be a huge mistake to
prohibit all collectors that stand any chance of being a real
improvement over the current situation.