Hacker News Reader

Comment by Tozen | Hacker News Reader

I think many people look at GC in the wrong way, as if absolute maximum speed is always the goal. It depends on what the goal is, and GC performance can be as fast as needed or enough. GC is also a convenience, that many may find worthwhile, to not worry about memory management.

Optional GC, also means you are free to go for it manually, if there is really and truly some bit of extra performance needed. In regards to language wars, it's arguably better to make the case of how to make manual memory management more convenient to use, when the optional GC is turned off.

View on HN

The GC made sense in comparison to C style memory management. But with with Swift, Rust and modern C++ the argument can be made that GC doesn't bring anything to the table.

In the beginning the biggest drawback seemed to be performance, so people have been hell-bent on fixing that for decades now. Completely ignoring that the "don't need to care about memory" mindset is flawed. You always need to think about memory, and if you do you might as well do it yourself. It doesn't take more time to do in the long run and you are forced to design a better system because of it.

For scripts it is a really nice have. But for a proper language writing large-scale applications? No thanks.

> But with with Swift, Rust and modern C++ the argument can be made that GC doesn't bring anything to the table.

GC will always be needed to solve problems dealing with general graphs containing possible cycles. Not coincidentally, this describes many of the GOFAI problems for which GC (in the context of LISP) was first developed.

I mean, what you’re saying is probably technically true for very specific problems that are contrived specifically to show shortcomings in refcounting, but in practice I’ve never seen it matter.

Weak and unowned pointers are pretty simple to deal with, and I’ve never seen a situation where it’s really confusing whether a pointer should be strong or weak in swift. Everything mostly just works, and if you need to point back to the object that owns you, it’s usually pretty clear by the abstraction you’re building that you need a weak/unowned reference to do it.

> and if you need to point back to the object that owns you

That's not the interesting case; that is indeed easily addressed by "weak" pointers. What's interesting is the case of a spaghetti reference graph where none of the objects definitely "owns" any other, and even the choice of GC roots might be dynamic.

The specific point I’m making is that the “interesting case” is rare. Rare enough that I’ve never seen it in person.

> But with with Swift, Rust and modern C++ the argument can be made that GC doesn't bring anything to the table.

With Rust and C++ (don't know about Swift), you still have to spend a lot of time thinking about memory.

> With Rust and C++ (don't know about Swift), you s still have to spend a lot of time thinking about memory.

You don't think about memory, you just think about how to ensure that you're always referencing live objects. And you need that kind of thinking anyway to deal with non-memory resources, where a GC won't help you at all.

"You can't garbage collect file descriptors" is a very weak argument.

My argument is that you always need to think about memory - even in GC languages. Being able to not think about memory is not a feature, it is a problem.

Why? It's a low-level implementation detail. Should you also always think about registers and jumps?

It is absolute not a low level detail, it is a huge part of your application and cannot be ignored.

Interesting, I've made many programs without caring about memory management and they worked just fine.

It completely depends on what application you're creating if it can be ignored or not.

You can just ignore it all almost as long as you stick to RAII and keep customizing allocators where you need. It is quite reasonable bc you can start to code fast and later imprpve performance in the allocation patterns.

There are other ways such as customozong new/delete.

Custom allocators definitely count as thinking about memory. Possibly also RAII.

True. But pauses due to a GC also counts as thinking about memory...

Depends on your situation what you can or cannot do/afford.

Swift is a GC language, reference counting is a GC algorithm as per CS literature.

Modern C++ unfortunely still has too much people writing classical C with classes, to make it properly safe.

Rust, yes, affine types are great, but their usability is only justified in scenarios where having any kind of automatic memory management isn't acceptable.

> But with with Swift, Rust and modern C++ the argument can be made that GC doesn't bring anything to the table.

Well, it would be a bad argument :D

A reference counter is arguably the slowest option, so Swift is out of the picture (besides it leaks circular dependencies). Rust is a good idea, but it is a tradeoff. Quite a lot of programs can’t be expressed with strictly tree-like lifecycles, and then you are either left with the yet again slower (A)RC, or unsafe. C++ is in pretty similar shoes. They are good for the niche they were made, systems/low-level programming.

Let me quote from the Garbage collector handbook: “above all, memory management is a software engineering issue. Well-designed programs are built from components [..] that are highly cohesive and loosely coupled. [..] modules should not have to know the rules of the memory management game played by other modules. [..] GC uncouples the problem of memory management from interfaces.”

It says nothing about not thinking about memory, you are free to optimize it where you need it.

EDIT: Oh and dynamic allocation is much faster with a modern GC than with malloc and friends, plus a moving GC can defragment heap.

> A reference counter is arguably the slowest option, so Swift is out of the picture

It's not that simple. Obligate refcounting has lower throughput than obligate tracing GC but offsets that with more predictable latency, which might be good for the Swift use case. Rust uses a mix of stack-based allocation, manual heap allocation and RC - and the RC only needs to manage "owners" as determined via the borrowck, as opposed to ephemeral references. So is way more efficient than something like Swift ARC, where refcounting is essentially ubiquitous and any operations via references will incur slow atomic RC updates.

Well, ever seen a C++ program that seemingly finished execution, but still haven’t exited?

That’s shared pointers recursively freeing up their reference trees. There is a great paper showing that RC tracks object death, while tracing GCs track object “liveness”, so its essentially two sides of the same coin.

As for RC, sure, at compile time many of the work can be omitted, but atomic writes needed for the counters are fundamentally slow operations on modern architectures.

You can do reference counting without making it atomic, by prohibiting sharing across threads. It’s not fundamentally required. See Rust’s Rc, for example.

or boost local shared ptr

> The GC made sense in comparison to C style memory management. But with with Swift, Rust and modern C++ the argument can be made that GC doesn't bring anything to the table.

Haskell needs a GC too. You can't do ergonomic functional programming without GC (it has been attempted).

Haskell needs a GC because it can't figure out whether a closure might outlive any of the variables it references. This can be addressed by a Rust-like borrow checker. (In the rare general case where multiple independent pieces of code need to keep some object alive, this can be done via refcounting which of course is a kind of GC.)

Type based memory management has been done in FP languages. The point is that it completely breaks the experience.

gc makes it easier to conceive of and program algorithms that use cyclical graphs, a pretty broad problem. try and implement these structures in rust and you quickly run into headaches. solveable headaches but headaches all the same. they’re trivial in a gc language

>GC is also a convenience

“Convenience” makes it sound like syntax sugar, it’s not merely convenient.

It eliminates certain types of bugs fundamentally, often it can simplify how the code is reasoned about.

"Convenience" is exactly right and syntactic sugar is underrated.

Just like static typing is a convenience. And dynamic typing is a (different) convenience. And unit tests are a convenience.

The computer runs fine without any of these. And none of them are a magic wand that eliminates all bugs. Instead all of them make debugging easier by reducing the search space, usually eliminating fairly trivial bugs. Which is more useful than it sounds because a lot (the majority?) of bugs are pretty trivial and at the same time hard to find because they are often so trivial that they stare us in the face and we can't see them.

But again, all these things are conveniences for the human programmer, they don't make one iota of a difference for the actual computer running the bits.

I always discuss about SLAs when arguing about language X vs Y.

Even if language X loses in microbencharks against language Y, if the application written in X is still within the project delivery SLA for acceptance testing, who cares about the microbencharks.

If I understand you right, then following your logic, all programming languages are conveniences. The computer runs just fine if we give it a binary to execute. It's not clear to me where you'd draw the line.

Is that wrong though? Compilers are "just" a kind of program that runs on our computers that afford us the convenience of writing programs in a more human friendly manner. The main argument in my mind against considering programming languages an awesomely powerful convenience would be that this is reductionist and that in the same manner, literally every invention ever was just a convenience as well.

But maybe the view of modern society as a tower built on the back of a million million one time conveniences that have since become indispensible isn't that far from the truth either?

It's not always a convenience. Perhaps when dealing with the potential elimination of certain classes of programmer error, but there are definitely use cases where specialized GC can solve runtime problems more efficiently than hand-written memory management.

As a real world example, consider a firmware boot loader I wrote for a previous client. They needed to apply code polymorphism (think, extreme ASLR) when they applied an over-the-air update or a factory reset of firmware. This is part of their defense in depth strategy: if a gadget attack were discovered in their system, they wanted to mitigate its effectiveness across all deployments. The problem with this approach is that boot loaders are tightly space constrained. To implement a sound code polymorphism strategy, around a dozen different heuristics must be applied in several passes over the code. These heuristics had to be weighed against timing and cache coherency constraints in the code under mutation, but most critically, these heuristics had to fit in the very limited space set aside for the boot loader. The GC was an optimization. It significantly reduced the code size of the heuristics.

> Instead all of them make debugging easier by reducing the search space, usually eliminating fairly trivial bugs

The last 50 years of CVEs suggests they're not so trivial.

You're right, I should have specified that I meant trivial in terms of cause, not in terms of impact.

That's why static typing and unit testing are both practically much better at reducing bugs than they have any right to be theoretically.

I actually find it easier to leak with gc than without. Gc effectively hides the problem well, while non-gc is easy to debug with tools like valgrind.

GCs don't eliminate leaking, they eliminate use-after-free, and can also be used together with other language design choices to eliminate any kind of memory corruption (like in Java).

Indeed, many think of GC languages as if GC was the only way to allocate memory.

Java is one of the languages to blame for such misunderstanding, many other languages, even Lisp variants like Interlisp and Common Lisp, provide all the tooling to manage resources like one would do in C and co languages.

Having a GC doesn't preclude those other features.

On D's case, we have the problem that language designers are against moving the GC forward, as they refuse to introduce managed pointers alongside untraced pointers.

So even optimizations that Mesa/Cedar, Modula-3 and Active Oberon were capable of before D came to be, aren't possible in D with its current language design.

> we have the problem that language designers are against moving the GC forward

This is incorrect. There even was a concurrent collector written for D, but it failed for technical reasons, not anyone blocking it.

The idea that I would block any improved GC implementation for D is just silly. D is free and open source and Boost licensed. I couldn't possibly stop anyone from doing a better one.

You're free to prove me wrong about what can be done, I would welcome your implementation!

Plenty of languages have already proven D wrong, as mentioned on my language list, my contribution isn't required.

C# already offers what I care about in managed languages with C and C++ like capabilities.

And honestly why would anyone go through the trouble to prove you wrong, if in the end it eventually has the same fate as the concurrent one, that only works in Linux anyway.

We didn't adopt the concurrent one because nobody could figure out how to make it work on platforms other than Linux. Everybody wanted it.

I'm curious why you don't use Managed C++ (the one with separate GC pointers)?

I do, and it isn't called Managed C++, rather C++/CLI.

Managed C++ was replaced by C++/CLI in .NET 2.0.

It is the best way to write bindings to native libraries on the .NET ecosystem without having to bother with getting P/Invoke or COM bindings attributes quite right.

However it is constrained to Windows, so for portable .NET code, P/Invoke it is.

Its use seems to be constrained to when one needs such a bridge. Not really a ringing endorsement.

Because C# covers all bases, specially since they started bringing Midori features into C# 7 onwards, as I mentioned, I only use it for non portable code out of convenience.

In fact C# actually has three models of pointers, regular references, JIT intrisics like IntPtr/UIntPtr and raw unsafe pointers.

(~gc side-track Walter) Has anyone ever tried using a caching model for application memory? LRU evict memory objects to disk w/ a pseudo persistent memory application behavior?

Your keyword here is 'transparent persistence' (or 'orthogonal persistence'). There was quite a lot of work on this a few decades ago - https://dblp.org/db/conf/pos/index.html

Thanks for the refs.

p.s. those seem to be persistent object focused. Persistence in a caching memory model would be a side-effect (and doesn't even have to be used). Do you know if there exists research primarily focused on 'a caching memory model' as an alternative to (general) GC or reference counting strategies?

Oh, I see. I am not aware of any work in that domain. Caching tends to be rather application-specific; despite all that phk says about varnish, mmap is not really a good general solution to the problem. Something language-specific with some awareness of the object model and perhaps access patterns could be an improvement, but not, I think, more than an incremental improvement.

It's an idea that its been attempting to get me seriously interested /g for a while now. I didn't wish to assert novelty (but to date haven't found anything).

The general idea is pretty straight forward, you have a ~fixed size chunk of (virtual) memory that active memory objects reside in. Garbage and very rarely used references get flushed to disk. Presumably, if the operating memory requirements (i.e. active objects) are met by available Ln cache layer, this should be a viable alternative to 'collecting garbage'. We're trading the overhead of tracing/ref-counting with the cost of cache mechanism. If cache is tiered, then the 'garbage' & 'rarely used' objects will end up in nice VM blocks that OS will flush to disk. One approach basically requires the use of one annotation at language level to distinguish 'long lived' objects.

Something like "Address/memory management for a gigantic LISP environment or, GC considered harmful" <https://dl.acm.org/doi/10.1145/1317203.1317206>? I think that uses usual LRU mechanisms to determine what to page though.

Which concurrent collector is this?

The one Rainer Schuetze worked on.

The one that's in druntime at the moment? Or a real concurrent GC, there are currently two different parallel GC's in druntime as I write this i.e. a forking one and a parallel marking one one which is enabled by default.

I know of a third GC implementation, by Rainer. Which is concurrent on Windows via snapshotting (but not in druntime).

http://rainers.github.io/visuald/druntime/concurrentgc.html

Reply on news.ycombinator.com