Hacker News Reader

Comment by pjmlp | Hacker News Reader

Swift surely has garbage collection. Reference counting is a garbage collection algorithm.

You can't just redefine a word that a person has already defined (albeit implicitly), in order to make them wrong. That's not how being right on the internet works. If you want to be right on the internet, you have to define the word before they do.

He's not redefining it. It was defined in the 70s.

https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

Reference counting is definitely a method of garbage collection.

This is just terminology. The important question here is: "Can your program leak memory?"

I think Raymond Chen once noted that garbage collection just aims to give the programmer the illusion of infinite memory under the assumption that only finite amounts of memory are every in use at once, while also absolving them from having to release memory manually.

So if your program allocated less than available, doing nothing would be a valid GC strategy as your program never hit an upper bound in what it can allocate.

I found that an interesting way to think about the problem because it's more concerned with what GC enables instead of what it strictly does. The former is always the same, no matter the GC implementation, but the latter can vary considerably (doing nothing, reference counting, mark-and-sweep, full concurrent and compacting GC, ...).

> garbage collection just aims to give the programmer the illusion of infinite memory under the assumption that only finite amounts of memory are every in use at once, while also absolving them from having to release memory manually.

Interestingly, this is also the description of Virtual Memory. https://en.wikipedia.org/wiki/Virtual_memory

The risk of memory problems don't disappear because of any form of GC. The problems are just different, and leaks are still quite possible.

They're possible, but not nearly as common. Back when I was coding C++ full time I spent most of my debugging time chasing down memory leaks and out-of-scope variables. Then in a decade of Java programming I think I had one memory leak.

But that's a two-edged sword. Many Java developers, especially those recently out of school, who have never had a C or C++ background, think the GC is a magical blanket that takes care of everything, and as a consequence they don't have an intuitive grasp of the true costs of memory. They just throw things around like it's no big deal. I've interacted with a lot of C++ developers who were hired to rewrite large Java applications in C++ for performance reasons, when really Java could have handled it if only the developers understood memory better.

GC is an abstraction that can work well but can also interfere with how a developer thinks.

> I've interacted with a lot of C++ developers who were hired to rewrite large Java applications in C++ for performance reasons, when really Java could have handled it if only the developers understood memory better.

Yep, this is a big issue.

Another good example is copying arrays of primitive types with for loops instead of using intrisics like System.arrayCopy().

Or using lists instead of arrays.

Sure there are many situations where there is no another way other than step out of the JVM into C++, but many could be avoided with better code as well.

I have not redefined anything.

http://gchandbook.org/

Chapter 5.

One of the best CS references in GC algorithms.

I can post links to 70's papers if you wish, specially ones related to Lisp research.

I add the remark here: in some literature, especially older, Reference Counting is not listed under Garbage Collection, but under Automatic Memory Management or Automatic Storage Reclamation.

See page 6, remark 7 in 'Uniprocessor garbage collection techniques', Paul Wilson:

http://scholarworks.rit.edu/cgi/viewcontent.cgi?article=1322...

Then C++ is also garbage collected.

Kind of, but only because C++11 defined a pluggable GC ABI.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n267...

Also, there are the C++/CLI and C++/CX that support GC at language level.

Now std::*_ptr<> types don't count to make the language GC, because their use is not enforced by the compiler.

Why should it be enforced by the compiler?

We're talking about garbage-collected languages (and "language" traditionally includes the standard library), not garbage-collected-only languages.

I mean, by your definition, C# also doesn't count, because it has unmanaged pointers in it.

Totally different.

In C#, GC is part of the language semantics and its interaction with unmanaged pointers is well defined in the language semantics standard, including how the memory is pinned when unmanaged pointers need to access GC allocated memory.

My point is that you're arbitrarily drawing a line between core language and its standard library, that is meaningless in practice.

If reference counting is a kind of GC, and the standard library offers reference counting, then the language offers a kind of GC - same as if the language itself had a built-in refcounted pointer. There's simply no practical difference here.

No, because there is nothing in the language that requires making use of that specific library.

It only makes sense to talk like that, if the language semantics define a relationship between the language and library requiring the library to always exist as a form of runtime and how the use of that runtime relates to language constructs.

If I can just throw away the library and replace it by something else where those types aren't available and still make use of 100% of the language features, this relationship doesn't exist.

That's splitting hairs to the point where the difference is not relevant for any practical purpose.

There's a single document defining what is ISO C++. It defines both the language and the standard library. Therefore, to "write in C++", by default, means to write code that uses and relies upon both the language semantics and the standard library functionality. Which means that std::shared_ptr etc is readily available, and is the standard way to use refcounting-based GC in C++.

Hence, ISO C++ is a language with optional refcounting-based GC.

> Now std::*_ptr<> types don't count to make the language GC, because their use is not enforced by the compiler.

Then you also shouldn't say that Swift is garbage collected.

Swift RC is managed by the compiler and is visible in the type system and language semantics.

C++ language definition doesn't give any special treatment tostd::*_ptr<> types regarding compiler semantics. They could be be something else.

Only partially, in Swift, it is still up to the user to cleverly work around scenarios that the system does not catch. Which is why you have weak references and other many tricks in the language to circumvent infinite reference cycles and related problems. It's hard to call language garbage collected when you have to deal with all that stuff yourself. Just look at the stuff you have to do sometimes in your closures to avoid them creating memories leaks.

In that case C++ has garbage collection too with std::shared_ptr. I guess 1 is a count too so also with std::unique_ptr.

C++ has a GC ABI introduced in C++11 and the dialects C++ Builder, C++/CLI and C++/CX do have GC support at language level.

Library types like std::shared_ptr don't really count to say that a language has a GC, because their use, specially their correct use, is not enforced by the compiler.

And technically, also unique_ptr, which has a reference count of 1 or 0.

Indeed, according to these "ref counting is gc" folks, free(void *) is a garbage collector, so C has always been garbage collected since 1970.

No, because the language C doesn't provide any of the algorithms described here:

http://gchandbook.org

Although, there are conservative GCs for C that replace malloc () and make fre () a nop, they cannot release all memory properly due to C semantics.

I am pretty WildUtah was being sarcastic to be a more extreme version of my post. Or perhaps it was an attempt to expand the grey area.

Reply on news.ycombinator.com