Talk:Garbage collection (computer science)/Archive 3

Archive 1

Archive 2

Archive 3

Disadvantage: You can't have pointers, only references.

What exactly does this mean? Isn't the reference vs. pointer distinction a C++ism? Java certainly allows Null..uh, references, for instance, and things like the Boehm GC for C exists. Surely C has pointers? Ketil (talk) 13:59, 17 January 2012 (UTC)

Also, although it's not clear from the article, I'm fairly sure a modern GC doesn't have to touch the garbage, i.e. that it's running time will be proportional to the live heap only. This is a potential performance advantage over manual memory management, which requires the user to free every allocated object. Ketil (talk) 14:07, 17 January 2012 (UTC)

Dead Link

Link "OpenRTL - Contains a mark and sweep collector for a standard dynamic allocation heap, with precise scanning support." seems to be dead. — Preceding unsigned comment added by 194.25.238.250 (talk) 13:35, 25 July 2012 (UTC)

Reworded a Potentially Confusing Sentence

I reworded "The garbage collector can reclaim only objects that have no references.", because it is potentially confusing. Let X be an object and let Y be an object. Suppose that X references Y. Y can be garbage, if X is also garbage. Therefore, Y can be garbage, even though it has references that point to it. A trivial example of this scenario is cyclic references among garbage objects. — Preceding unsigned comment added by M17 (talk • contribs) 04:46, 25 October 2012 (UTC)

Minsky-Feinchel-Yochelson Garbage Collector Algorithm

Should this be mentioned? I heard about it on Lesson 10B of MIT's programming series from the 80s. Apparently at that time it was the fastest garbage collector algorithm, according to the lecturer. 209.66.74.34 (talk) 03:08, 11 December 2012 (UTC)

Garbage Collection in Hardware

Lisp machine it is mentioned that the machines were capable of garbage collection. No where is explained how exactly that worked. — Preceding unsigned comment added by Igalic (talk • contribs) 15:37, 22 January 2014 (UTC)

Non-deterministic GC is incompatible with RAII based management of non GCed resources

'Quertyus' added a 'Citation needed' to this. Is a citation really needed for something that obvious?

If RAII relies on a destructor being called (and being called in a relatively timely manner) for it to to be able to manage resources, and if non-deterministic GC gives no guarantees whatsoever that the destructor will be called (either in a timely manner, or even at all), than the fact that the two are incompatible should IMO be blindingly obvious and need no citation.

I thus would like to propose the citation needed be removed from this statement. — Preceding unsigned comment added by 92.70.45.2 (talk) 14:51, 19 February 2014 (UTC)

GC in C++ (and C, and Objective versions)

First theoretical: "Notable exceptions are C++ and Delphi which have destructors". Clang and Visual Studio have, since C++11, support the "Minimal GC support", while GCC doesn't.[1][2] So it seems to be possible. From what I understand (only) "conservative" GC (Boehm) is possible in C. I *think* the same applies to C++ even pre-C++11. As I understand it, it's a hack that is not portable but works. Where? I guess for specific processor or environments. What "Minimal GC support" does is make it portable (still only conservative and possibly the GC-runtime itself is not portable between compilers?). I'm I correct so far? Then, what is the problem with destructors? Or never mind, possibly just strike that out of the page. [I assume everything that works for C++ works for Objective-C(++) and C, and what works for C works for Objective-C, but (may) not C++.] [Bonus points, would (hard) real-time GC, that is incremental and even concurrent also be possible with C(++11)? I'm not seeing why the "Java" algorithms in theis page wouldn't work, only they would have to be Boehm-style.]

Practically what does this mean? Is there GC that actually works well for C++? Preferally portable to all compilers that have "minimal GC support". Note the "minimal GC support" doesn't provide GC, if I understand correctly, only that GC could be implemented portably.

According to the N2670 spec, this thread and this interview, that just opens a path for various C++ implementations to include automated garbage collection. So, yes, C++ finally became an officially dumb thing, but just optionally. — Dsimic (talk | contribs) 19:28, 25 March 2014 (UTC)

[Real-time] GC in hardware or OS level?

a) At high-level language computer architecture I found "Ericsson developed ECOMP, a processor designed to run Erlang.[3] It was never commercially produced." and on slide 9:

"Real-time garbage collection

GC performed concurrently in HW"

Know of any better example - at least implemented? Not sure we should add this one.. I couldn't even see it at Erlang (programming language)..

b) I've been thinking if GC should be added to operating systems and then found about D language..: "Garbage collection should be implemented as a basic operating system kernel service. But since it is not, garbage collecting programs must carry around with them the garbage collection implementation. While this can be a shared library, it is still there."[3]

about a) Lisp-machines are very famous, and Lisp has GC, not sure about the machines. Same with the "most popular" Java processor type of machine (and I do not think GC was implemented in them, at least by not by ARM). Should we say something about [real-time] GC in hardware? I'm not sure what kind of support is needed (or available) in any processor. It seems maybe no support needed/helpful? I can however see GC helpful at the OS level (with or without hardware support..) but hard to implement for many different languages running on that OS.. comp.arch (talk) 14:09, 2 December 2015 (UTC)

Patents. Eg. non-patented ((hard) real-time) GC algorithms

Are all real-time algorithms patented? I was very interested in seeing Staccado (see my recent edits). It seems to fulfill all important criteria for hard real-time GC algorithm. I found a patent that migh ally to Staccado (didn't read to carefully). It doesn't mention that name in title or in text. It however mentions Metronome a lot that it is based on. I assume Metronome is patented but do not know for sure: [[4]]. Azul uses a patented [5] algorithm, but they sell hardware. Should we say that algorithms are patented? It seems they (real-time) all might be? Let's say they all are and they expire in 20 years then anyone know if a soft or even hard real-time GC algorithm older than that is available (that could be used eg. for Java, or C/C++)? Seems patent-less hard real-time Java (or even soft) is not available for the next 15 years or so. While for C/C++ it is as GC is not needed. comp.arch (talk) 14:48, 13 March 2014 (UTC)

Hm, what about this? — Dsimic (talk | contribs) 19:20, 15 March 2014 (UTC)

Great, thanks. It doesn't say anything about patents or the date. I assume it's over 20 years old (references are old and it's about LISP) even though the html file is newer. Then the patents would be expired in the states (and everywhere?). I haven't looked into the algorithms enough in the article here, but they mentioned arraylets (and compiler support). I haven't thought it through, it seems arrays might be a problem. When I learned (about) LISP I didn't learn about arrays in it. As it is functional and based on linked lists maybe it helps if no arrays are used for real time. Doesn't (modern) LISP however also support arrays? And while the article you pointed to says real time, should we assume hard real-time? [Even if the GC is real-time and the rest of Java/programming language, would VM not screw that up possibly (be disabled?).] The new algorithms must have something better or they would not be thought up. Staccado is also concurrent, while Metronome is not but still an improvement I assume on what you pointed to. comp.arch (talk)

I agree that this article should mention real-time garbage collection algorithms. So I started a rough draft of a garbage collection (computer science)#Real-time section. --DavidCary (talk) 03:23, 6 December 2015 (UTC)