Reference count, don't garbage collect • Hacker News Board

Re: Reference count, don't garbage collect

#161

Post by eru » Sat, Jul 30, 2022, 3:09 AM UTC

freecodyx wrote: post #94

What if programming languages start offering both? In my opinion RC is GC in disguise. At least for example Golang GC has the merit to run in a separate thread(still has to stop the world when reclaiming memory back, and the memory allocator model is helping achieve great GC perfs).

Python does both reference counting and garbage collection.

Btw, GC is also often RC in disguise. What I mean is that generational garbage collectors are basically a hybrid of tracing GC and RC. See https://web.eecs.umich.edu/~weimerw/2012-4610/reading/bacon-... for the details.

Re: Reference count, don't garbage collect

#162

Post by eru » Sat, Jul 30, 2022, 3:11 AM UTC

amiga1200 wrote: post #96

Just allocate then deallocate manually, use neither auto methods.

What do you mean by 'manually'? Malloc and free still do lots of work.

Or do you want to manually assign memory addresses to your objects?

Re: Reference count, don't garbage collect

#163

Post by eru » Sat, Jul 30, 2022, 3:12 AM UTC

klodolph wrote: post #70

arcticbull wrote: post #62

Earlier quoted context omitted.

Nope, you can just mark the back-reference as weak. GC is only required if you as a programmer (or programming language) do not provide sufficient information to the compiler or runtime to understand the object graph.

It's not always obvious to know which reference to mark as weak, and there's not necessarily a clear indication of which reference is a back-reference. You can find various algorithms in journals or whatnot written with the assumption that there's GC. Algorithms designed with this assumption may not have clear ownership for objects, and those objects my have cyclic references. It's easy to say, "objects should have c…

And if you have really clear ownership, you don't need reference counting either..

Re: Reference count, don't garbage collect

#164

Post by eru » Sat, Jul 30, 2022, 3:12 AM UTC

rtfeldman wrote: post #124

jayd16 wrote: post #84

Is there such a thing as a compacting RC?

There was a great talk at Strange Loop about a drop-in malloc replacement which compacts. Apparently it actually led to memory usage improvements in industrial projects like Redis: https://youtu.be/c1UBJbfR-H0

See https://github.com/plasma-umass/Mesh for the code and a link to the paper.

Re: Reference count, don't garbage collect

#165

Post by eru » Sat, Jul 30, 2022, 3:14 AM UTC

mirekrusin wrote: post #17

What about - garbage collect by reference counting, like Python?

Python has reference counting for historical reasons, and added tracing garbage collection for dealing with cycles.

If you wanted performance these days, you wouldn't want to go for that architecture. It's a historically accident that they can't really free themselves from because of backwards compatibility.

Re: Reference count, don't garbage collect

#166

Post by eru » Sat, Jul 30, 2022, 3:15 AM UTC

bitwize wrote: post #24

Boy, I can't wait for theangeryemacsshibe (posts here as hayley-patton) to tear into this one. But yeah, the correct way to handle resources (not just memory!) is with value semantics and RAII. Because then you know the object will be cleaned up as soon as it goes out of scope with zero additional effort on your part. In places where this is not appropriate, a simple reference counting scheme may be used, but the ide…

Doesn't RAII only work when your lifetimes are in a nested hierarchy?

(Basically, your lifetimes have to be the same as your scopes, which are in a simple tree structure only.)

Re: Reference count, don't garbage collect

#167

Post by wesnerm2 » Sat, Jul 30, 2022, 3:16 AM UTC

rdw wrote: post #152

nemothekid wrote: post #142

Earlier quoted context omitted.

I don't know much about the C# garbage collector; and it's likely that garbage collectors are a bad fit for programs that have hard deadlines. That said, it could also be a function of the same "problem" Java has in its design - Java by default boxes everything and so every memory allocation increases garbage collection pressure. Go, by using escape analysis and favoring stack allocations, doesn't have this problem a…

You're right, and it's got more layers than that. C# does have value types, which are not boxed, and using them judiciously can avoid garbage. However, they are a more recent addition to the language (which started as a lame Java clone), and so the standard library tends to not know about them. Really trivial operations will allocate hundreds of bytes of garbage for no good reason. Example: iterating over a Dictionar…

C# had value types and pointers from the very beginning. These are not a recent addition. The standard library does know about them. However, not until C# 2.0, which introduced generics, were collections able to avoid boxing value types.

There are some cases where allocations are made when they could have been avoided. Iterating over a dictionary creates a single IEnumerator object. Async methods, tuples, delegates, and lambda expressions also allocate memory as do literal strings. It is possible to have struct-based iterators and disposers. There are some recently added mitigations such as a ValueTask, ValueTuple, function pointers, ref structs, conversions of literals to read-only spans, that eliminate allocations.

DateTime is a value type and doesn't allocate memory. Getting the current time does not allocate memory.

With the recent additions to ref types and Span, C# provides a lot of type-safe ways to avoid garbage collections. You can always use pointers if need be.

Re: Reference count, don't garbage collect

#168

Post by matheusmoreira » Sat, Jul 30, 2022, 3:29 AM UTC

klodolph wrote: post #81

arcticbull wrote: post #67

Earlier quoted context omitted.

> When I hear rhetoric like this, all I think is, "Oh, this person really hates GC, and thinks everyone else should hate GC." Yeah, I think it's an inelegant, brute-force solution to a language problem - and that we continue to throw good money after bad improving it. We should be investing in removing the need for GC through smarter compilers and through languages that allow us to better express our intent - and our…

> Yeah, I think it's an inelegant, brute-force solution to a language problem - and that we continue to throw good money after bad improving it. Having studied GC, implemented GC, and used it extensively (either as a dev or someone in operations) I'd say that there's just a lot of people out there who don't understand it. That's why people come to the wrong conclusion that it's somehow "inelegant" or "brute-force", w…

> And there's a lot of people who only have a vague idea of how GC works in theory

I agree. To better understand garbage collection, nothing better than implementation. This article is such a joy to read:

https://journal.stuffwithstuff.com/2013/12/08/babys-first-ga...

Re: Reference count, don't garbage collect

#169

Post by dataflow » Sat, Jul 30, 2022, 3:31 AM UTC

viraptor wrote: post #141

deterministic wrote: post #132

Earlier quoted context omitted.

I am the maintainer of a very high-performance JIT compiler for a Haskell like rules programming language used by large enterprises around the world. It uses reference counting + a global optimisation step to reduce the reference count updates to an absolute minimum. The result is compiled code that runs faster than C++ code carefully hand optimised by C++ experts over a 10 year period. There are zero GC pauses. Unle…

How do you collect cycles without a pause?

I'm gonna take a guess they dedicate a core to GC (or something along these lines).

Re: Reference count, don't garbage collect

#170

Post by RandomBK » Sat, Jul 30, 2022, 3:36 AM UTC

nemothekid wrote: post #90

It's my theory that Java, unintentionally, did a lot of damage to P&L research. I write a lot of Rust, and while the borrow checker is great, I've come to really admire the work that was put in the Go GC even if it's not as fast Java. There is a whole generation of programmers that have come to equate GC with Java's 10 second pauses or generics/typed variables with Java's implementation of them. Even the return to ty…

I feel that every time we talk about Java, we should clarify between Java the language, Java the programming style, and Java the JVM.

As a language, Java's not too bad. It's a bit wordy, in bad need of some syntax sugar, but it's designed to be fairly straightforward and for the most part it does its job well. I don't need a degree in language theory to get started writing it.

Java the programming style, particularly enterprise, is a horrendous over-engineered mess that schools jam down the throats of students who don't know any better. It's designed to (and fails to) enforce a common style that can be written by armies of mediocre developers plodding along inside giant enterprise codebases, so that no matter who wrote the code, some other developer in another department can figure out how to call it.

Java the JVM is a pretty nifty beast. It's made tradeoffs that means it's not always suited for every use case, but put in its element it really shines. The modern GC algos give developers options based on the program's needs. It's currently struggling to overcome some historical decisions that while good back in the old days are now holding it back.

Personally I'm very biased towards Kotlin, which gives me the benefit of the JVM without the barf that is Java. It's not the fastest-executing language out there, but for me it's a perfect balance between development speed, ecosystem of battle-tested libraries, and competitive execution speed.