Go does not need a Java-style GC

https://erik-engheim.medium.com/go-does-not-need-a-java-style-gc-ac99b8d26c60

by nahuel0x • 5 years ago

153 219 5 years ago

erik-engheim.medium.com

seunosewa• 5 years ago

I'm cautious about believing this sort of claim because I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready. However, the article convincingly explains who Java has a greater need for a compacting GC - it creates more garbage. This doesn't necessarily mean Go won't benefit from having a generational, compacting GC at some point, for some applications.

runevault2• 5 years ago

Even if it doesn't need specifically a compacting QC having a swappable more tunable one might still be a big deal for people who need something other than the current GC. Like a simple example is the Discord article about how their use case could not work with Go because it always ran the GC every two minutes. If they could optionally disable that feature they theoretically could have kept using Go instead of rewriting to Rust.

pkaye• 5 years ago

You can disable the GC in go. https://pkg.go.dev/runtime/debug#SetGCPercent

Andys• 5 years ago

The go gc was greatly improved in the versions subsequent to the ones used by Discord. The timing there was unfortunate.

lostcolony• 5 years ago

That wasn't my read.

The Discord team that wrote the article I believe you're referencing ( https://discord.com/blog/why-discord-is-switching-from-go-to... ) wanted GC, the problem was that they had a huge cache which took a long time for the GC to scan. They could shrink the cache and it would remain performant in the face of GC, but they took latency hits due to increased cache misses. After a bunch of testing and tweaking they found a goldilocks zone where performance was okay.

Rust was introduced because it was already something other teams were interested in, and when they tried a quick prototype, they avoided the issue entirely, and saw better performance even in the prototype than their finely tuned Go code, so they switched to it.

nemo1618• 5 years ago

I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready

Hey, us generics-naysayers are still out here (grumbling)! :)

mohanmcgeek• 5 years ago

The JVM world right now has quite a few GCs and your choice essentially dictates your program's performance tradeoffs.

But I'm not sure if there will ever be a point where this is true for Go considering how little gets into the stack compared to Java.

JulianMorrison2• 5 years ago

Go creates less garbage and also stack allocates things using escape analysis which as the article explains, is effectively a form of generational garbage collection.

kaba011• 5 years ago

As far as I know (I’m not too familiar with Go), Go mostly stack allocates based on the developer’s intent, eg. by using structs.

Java doesn’t (yet) have an option for value types that can be reliably stack allocated, so it resorts to very complex escape analysis. Calling the former escape analysis is a bit misleading imo, even if technically true.

masklinn4• 5 years ago

However it's a weak one, the stack allocation acts as a form of extremely limited nursery, but lots of "escaping" objects could well fit into a nursery, to say nothing of "heap" objects (like strings and slices) which always trigger heap allocations.

Furthermore AFAIK most generational GCs have 3 generations, not 2 (let alone 1.5).

It does make the tradeoff more complicated, a generational GC is not simple (especially in a language with ubiquitous mutability), but the casual dismissals are... troubling.

And that's before mentioning the regularly problematic lack of tuning knobs of the Go GC, also often dismissed as "java concerns" (which Go users have to work around using ugly hacks when hit, because they don't have tuning knobs).

socialdemocrat2• 5 years ago

Go designers never said they would never add generics. I've followed Go from the start and they have always been clear that they would consider adding generics if they found a good design for it. However they never had it as a high priority.

Many Go fans have said does not need generics, and many including myself would still argue that it doesn't need generics. Yet I cannot say I mind that Go adds generics. I am just worried about whether Go manages to retain its simplicity. Time will tell.

I have been a professional Swift programmer who has had ALL the features people have been shouting about for years that Go should have, yet it cannot be said to be a better language. A lot of these features also make Swift more clunky to use than Go in many instances.

Having said that, I like both Swift and Go. I just cannot see that more is always more.

bitwize• 5 years ago

What it needs is Rust style static lifetime management.

Yoric5• 5 years ago

As a Rust developer, contributor and generally a big fan of Rust, I'd tend to disagree. Having a garbage-collector is a lifesaver for many algorithms. Static lifetime management is great but isn't something you want to force developers to use when they're more interested in coming up with solutions quickly.

Also, I really don't see how it would work in Go. You require a pretty strong type system to make static lifetime management work. Unless something has changed radically in the recent past, that's not something that the Go community had much interest in (yes, I know that generics are one step in that direction, but I'm not aware of further steps being discussed).

IceWreck• 5 years ago

You require a pretty strong type system to make static lifetime management work

Go is strongly and statically typed.

AtlasBarfed• 5 years ago

If you're at the point that serious GC performance is being examined, then a rewrite to rust is something that should be considered on the strategic roadmap if it is code you have control over (versus third party / OSS software).

I think Go has a maximum expansion footprint. People presumably use Go because it is faster and better GC than Java. Rust will probably eat a lot of that territory. That will leave people that like it strictly for language/idiomatic reasons, and that won't be enough.

The entire meta-point of the post is to try to argue that Go is "better" than Java GC-wise. Well, it is and it isn't in reality, as benchmarks and people in the know have said. If it is "better" it is a very unconvincing win.

As someone wise said 10 years ago, you almost need 10x the performance to have a convincing improvement to get laypeople to notice, and to get dev people to consider switching from legacy/entrenched ways of doing things.

Here, there's basically no real world improvement to point to.

natanbc• 5 years ago

In a multithreaded program, a bump allocator requires locks. That kills their performance advantage.

Java uses per-thread pointer bump allocators[1]

While Java does it as well, it doesn’t utilize this info to put objects on the stack.

Correct, but it does scalar replacement[2] which puts them in registers instead

Why can Go run its GC concurrently and not Java? Because Go does not fix any pointers or move any objects in memory.

Most java GCs are concurrent[3], if you want super low pauses you can get those too[4][5]. Pointers can get fixed while the application is running with GC barriers

[1] https://shipilev.net/jvm/anatomy-quarks/4-tlab-allocation/

[2] https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacemen...

[3] https://shipilev.net/jvm/anatomy-quarks/3-gc-design-and-paus...

[4] https://wiki.openjdk.java.net/display/zgc/Main

[5] https://wiki.openjdk.java.net/display/shenandoah

majou2• 5 years ago

ZGC[4] in particular has me excited, enough so to want to pick up a JVM language.

the-alchemist• 5 years ago

ZGC is already available, since JDK 15, September 2020. =)

https://wiki.openjdk.java.net/display/zgc/Main#Main-ChangeLo...

Thaxll3• 5 years ago

ZGC and Shenandoah can be slower than G1, those are not silver bullets. The fact that there is 4-5 GCs explains the situation, there is not a single GC that is better than the others.

It really depends of the workload.

sam_bishop2• 5 years ago

I agree. The author seems to know quite a bit about Go and GCs, but doesn't seem to have much experience with Java. As a Java performance engineer, it sounds like he is comparing Go to how he thinks Java works based on what he's read about it.

pjmlp12• 5 years ago

Additionally he doesn't seem to know that much about C#, which also has advanced GC, while allowing for C++ like memory management, if needed.

mappu2• 5 years ago

"Scalar replacement" explodes the object into its class member variables and does not construct a class object at all. That does result in the exact same `sub %esp` (that Go would do for any struct), but it is restricted to only working if every single usage of that class type is fully inlined and the class is never passed anywhere that needs it in its object form.

It's worse than what Go has. Go can stack-allocate any struct and still pass pointers to it to non-inlined functions.

pkolaczk2• 5 years ago

Scalar replacement does not work even in very trivial cases: https://pkolaczk.github.io/overhead-of-optional/

In all those cases, Optionals were inlined, didn't escape, yet they haven't been properly optimized out.

altfredd2• 5 years ago

Scalar replacements (as currently implemented in Java) does not work in real-world programs.

Well-written code does not need it. Poorly written code can not trigger it, because the JIT is too dumb and isn't getting better.

There is no sane test to determine whether a piece of code will be inlined in Java. In practice anything more complex than byte array is unlikely to be inlined. Even built-in ByteBuffers aren't! Meanwhile Go compiler treats Go slices just as nicely or better than arrays.

pjmlp12• 5 years ago

Which JIT? There are plenty of them to choose from across Java implementations.

native_samples6• 5 years ago

The JIT is getting better. Major escape analysis upgrades are a big part of where Graal (a drop-in replacement for the HotSpot JIT) gets its performance boosts. EA definitely does work well there because Truffle depends on escape analysis and scalar replacement very heavily. GraalVM CE is better than regular HotSpot at doing it and GraalVM EE is even better again.

Yoric5• 5 years ago

I'm a bit skeptical.

Yes, Go has value types and pointers. But whether you need a modern GC will undoubtedly depend a lot on the type of algorithms you need to execute. Also, it's great that you can implement (some form of) allocators, and that will definitely help for many algorithms, but that's definitely a case of tradeoff between convenience and readability. Similarly, unless I'm mistaken, TCMalloc "solves" fragmentation in two cases: either allocations are small (very common) or memory allocation maps neatly to threads (much less common). That's two good cases to have, but I wouldn't count on it solving memory allocation on its own for, say, a browser engine or a videogame.

Oh, and hasn't Java's GC been fully concurrent for a while now?

That being said, revisiting the assumptions made by Java (and other languages) is a very good idea.

avita1• 5 years ago

Cool article, I'm not sure I agree with the headline.

I used to write low-scale Java apps, and now I write memory intensive Go apps. I've often wondered what would happen if Go did have a JVM style GC.

It's relatively common in Go to resort to idioms that let you avoid hitting the GC. Some things that come to mind:

* all the tricks you can do with a slice that have two slice headers pointing to the same block of memory [1]

* object pooling, something so common in Go it's part of the standard library [2]

Both are technically possible in Java, but I've never seen them used commonly (though in fairness I've never written performance critical Java.) If Go had a more sophisticated GC, would these techniques be necessary?

Also Java is supposed to be getting value types soon (tm) [3]

[1] https://ueokande.github.io/go-slice-tricks/

[2] https://pkg.go.dev/sync#Pool

[3] https://openjdk.java.net/jeps/169

bestinterest• 5 years ago

How have you found Go in contrast to Java. Is the simplicity worth it?

jatone9• 5 years ago

yes. golang is actually less restrictive than java. and avoids a ton of the bullshit abstractions you see in every java code base.

papercrane• 5 years ago

Object pooling in Java used to be fairly common. I don't see it much anymore in new code, but used to run into it all the time when writing code for Java 1.4/5. Even Sun used pooling when they wrote EJBs. Individual EJBs can be recycled instead of released to the GC.

Nowadays the GC implementations are good enough that's it's not worth the effort and complexity.

Though now that I think about it Netty provides an object pooling mechanism.

munificent• 5 years ago

Both are technically possible in Java, but I've never seen them used commonly (though in fairness I've never written performance critical Java.)

I don't know about the Java world, but in C#—especially in games written in Unity—object pooling is very common.

TideAd• 5 years ago

Writing High Performance .NET Code (https://www.writinghighperf.net/) has a chapter on this. In C#, time spent collecting depends on the number of still-living objects. That means you want objects you allocate to be short-lived (dead by the time GC happens) or to live forever (they go to the gen 2 heap and stay there). The book suggests object pooling when the lifetime of objects is between those two extremes, or when objects are big enough for the Large Object Heap.

But at the end of the section, the book says:

  I do not usually run to pooling as a default solution. As a general-purpose mechanism, it is clunky and error-prone. However, you may find that your application will benefit from pooling of just a few types.

What kind of things do you pool in Unity?

adrr• 5 years ago

I've seen it on a large site written in c#. Object pools of stream objects for serializing and deserializing data. This was 10 years ago.

jillesvangurp2• 5 years ago

Java has a pretty decent standard library with different list, map and set implementations and quite a few third party libraries with yet more data structures. Honestly, Go felt a bit primitive and verbose to me on that front on the few times I used it. Simplicity has a price and some limitations.

There are also other tricks you can do like for example using off heap memory (e.g. Lucene does this), using array buffers, or using native libraries. There obviously is a lot of very memory intensive, widely used software written for the JVM and no shortage of dealing with all sorts of memory related challenges. I'd even go as far as to argue that quite a few of those software packages might be a little out of the comfort zone for Go. Maybe if it were used more for such things, there would be increased demand for better GCs as well?

Object pooling is pretty common for things like connection pools. For example apache commons pool is used for doing connection pooling (database, http, redis, etc.) in Spring Boot and probably a lot more products. Also there are thread pools, worker pools and probably quite a few more that are pretty widely used and quite a few of those come with the Java standard library. Caching libraries are also pretty common and well supported popular web frameworks like Spring.

A typical Java based search or database software product (Elasticsearch, Kafka, Casandra, etc.) is likely to use all of the above. Likewise for things like Hadoop, Spark, Neo4j, etc.

Of course there's a difference between Java the language and the JVM, which is also targeted by quite a few other languages. For example, I've been using Kotlin for the last few years. There are functional languages like Scala and Clojure. And people even run scripting languages on jython, jruby, groovy, or javascript on it.

There even have been some attempts to make Go run on the JVM. Apparently performance, concurrency and memory management were big motivators for attempting that (you know, stuff the JVM does at scale): https://githubmemory.com/repo/golang-jvm/golang-jvm

Their pitch: "You can use go-jvm simply as a faster version of Golang, you can use it to run Golang on the JVM and access powerful JVM libraries such as highly tuned concurrency primitives, you can use it to embed Golang as a scripting language in your Java program, or many other possibilities."

geodel14• 5 years ago

There even have been some attempts to make Go run on the JVM. Apparently performance, concurrency and memory management were big motivators for attempting that (you know, stuff the JVM does at scale):

This seems legit. Just links to their website/Wiki are not working right now.

fl0ki• 5 years ago

Not sure if you're in on the joke, but for those who didn't go to the repo itself:

https://github.com/golang-jvm/golang-jvm

It's just a copy-paste of JRuby on April 1st and the readme now includes a rickroll.

Maybe it's irresponsible of them to leave it up in a way that Google still finds as a legitimate-looking search result.

sam_bishop2• 5 years ago

Pooling objects (for the purposes of minimizing GC) is consider a bad practice in modern Java. The article suggests that compacting, generational collectors are a bad thing, but they can dramatically speed up the amount of time it takes to deallocate memory if most of your objects in a given region of memory are now dead. All you have to do is remove objects that are still alive, and you're done: that region is now available for use again. The result is that long-lived objects have a greater overhead.

fh973• 5 years ago

Does object pooling still make sense for direct ByteBuffers nowadays?

javier2• 5 years ago

Object pooling used to be more common in Java. Now it is mainly used for objects that are expensive (incurs latency) to create, not for GC reasons.

jeffbee3• 5 years ago

There are very few falsifiable statements in this article but the extant ones are all demonstrably false, starting with this whopper:

"This typically causes Java programs to have complete freezes of several hundred milliseconds where objects get moved around"

Yeah, i mean, definitely not. The only language I regularly work with that has this property is, surprise, Go.

The proof is in the tasting, as they say. Go look at the gRPC daily benchmarks if you want hard data. Java beats Go latency at the median and at the tail while having substantially better specific throughput. In other words the Java GC has no tradeoff versus the Go GC; it is better in every way.

Thaxll3• 5 years ago

The Java gRPC SDK is heavily optimized by Google, much more than the Go one. Until recently Java pauses were a real issue,

I worked with a lot of Java based solutions ( elastic search, hadoop etc ... ) and was never impressed by the GC.

jeffbee3• 5 years ago

Maybe, but it's still not possible that the Java test has a median latency of 150µs, a tail latency of 350µs, and a regular need to stop the world for hundreds of milliseconds. That statement is simply not compatible with reality.

kaba011• 5 years ago

While I agree that the java gRPC lib is better maintained, I don’t agree with your second point. Java’s GCs are the state of the art, that can manage heap sizes up to 16 terabytes. Other GC implementations would simply die there.

feffe• 5 years ago

To be fair, early Java definitely had lots of issues with GC and "hanging" programs due to GC activity. It's a failure of the article to bring it up if modern Java implementation are better on that point. As an example of bad reputation, I think the latest Eclipse IDE on the latest Java SDK is still sucky and because of my ignorance I blame it on Java.

I was disappointed with the first Go gRPC implementation, it allocated like crazy and was really slow because of it. It's been rewritten since then but I don't know how much better it is now. To get good performance out of Go it is important to think about memory allocations (unfortunately), just as it is in C and C++. Although allocating like crazy in C/C++ will probably mostly result in a general loss of performance, not affect tail latencies in network protocols much.

moltenguardian• 5 years ago

gRPC Java wins in part due to not allocating memory when reading and writing buffers. It uses Java-based implementation of jemalloc (via Netty) to manage its own memory. No/low allocations means the GC doesn't need to wake up so much.

jatone9• 5 years ago

i've literally experienced worse pauses from java (sometimes surpassing 30s) GC due to allocation. granted it was pre the latest G1 GC. but they absolutely exist and many companies run on older versions of java.

and I doubt you see pauses in golang longer than 30ms. proof please.

kaba011• 5 years ago

Comparing apples to oranges. Java has been around for multiple decades so there may be some bias on your part based on very old examples, but also, your “average” java program is more likely much more complex and larger code base than your average go one.

Also, shitty code does get written by developers quite often, regardless of language — at that point the runtime can only do that much.

Ericson23144• 5 years ago

This is mostly stupid. Being able to have many GCs is a good thing. The big reason for "value types" is controlling spacial locality in memory, not GCs being bad per-se.

Also, they undersell the java/c# situation. C# has "ref, out, or in", but even without those, you can always make a reference wrapper that has the value type as a field. So "reference types suck because coppying" is nonsense garbage.

throwaway8943452• 5 years ago

I mean, I’ve dabbled in all of these languages, and I much prefer Go’s value types to ref, out, in, and a half dozen GCs. It’s nice that these VM languages have a distinct thing for every eventuality, but I much prefer a single thing that works 99% of the time.

Ericson23144• 5 years ago

I usually am bashing Go :D, but I am not this time.

I am saying this blog author is confused on what the runtimes are capable of. I don't mean to say ref out and in are good language ergonomics or whatever, but simply that they show the compilation target is capable of expressing thing these things.

The only thing I know of that the go runtime can do that these others can't is "interior pointers", i.e. pointers to a field of a larger object. You can always just copy the field into a new box, but that breaks mutation semantics. Java gets away with this precisely because most fields are themselves boxed...bu that's exactly the no-control-over-locality problem we're trying to solve.

joelfolksy3• 5 years ago

Why do you much prefer

  func changeName(p *Person) {
    p.firstName = "Bob"
  }

  void changeName(ref Person p) {
    p.firstName = "Bob";
  }

?

yakubin2• 5 years ago

The big reason for "value types" is controlling spacial locality in memory, not GCs being bad per-se.

Spacial locality is one reason. Another very important reason is not generating unnecessary garbage. If you have a lot of microallocations, then your program is going to be slow regardless of you using manual memory management, RAII or a tracing GC. There is just a lot more stuff to do. With manual memory management, you're just going to call free() a lot (using big forward linked lists and freeing them with a function iterating over them, calling free() on each node? yikes). With RAII you're going to spend a lot of time in destructors due to an avalanche of objects freeing the objects they own (structs holding unique_ptr/shared_ptr to structs holding unique_ptr/shared_ptr to...? std::vector<std::string>/std::vector<std::unique_ptr>? these are all antipatterns when it comes to performance). With GC, you're going to have long GC pauses, because the GC needs to traverse a bigger graph of pointers (deep/broad trees of heap allocated objects? arrays of boxed objects? yikes).

Another reason is eliminating unnecessary pointer indirection, which helps make sure that instead of loading data with two MOVs from memory polluting the cache, you need only one.

For my current project, I use arenas to opt-out of RAII and have just a couple points in my project where memory is freed, instantly in one go. Needless to say, I don't use arrays of boxed elements. It's working great for me. Not only is it faster, but also simpler to understand and I don't need to fight with the borrow-checker as much as in normal (RAII) Rust, because my objects are grouped into longer lifetimes, so I don't need to think about separate lifetimes for every distinct little object.

That said, I'm spending some time gathering ideas for a toy language I'd design for myself to write an OS from the kernel up to userspace in, and I'm leaning towards a GC-based design that relies a lot on value types. One way or another, allocating a lot of little objects is stupid, because in every scenario it makes your program slower and, code quality-wise, at best it doesn't make a difference, but a lot of times it makes your code harder to reason about, because now a lot of things are remote to the place in code you're thinking about at any given time.

Ericson23144• 5 years ago

If you have a lot of microallocations, then your program is going to be slow regardless of you using manual memory management, RAII or a tracing GC.

No, that's no true. Tracing GC is mainly O(f(live stuff)), not O(f(dead stuff)), so there is basically no problem making lot's of garbage if you don't have any exotic latency requirements.

Another reason is eliminating unnecessary pointer indirection, which helps make sure that instead of loading data with two MOVs from memory polluting the cache, you need only one.

Uh, that is locality, what I started with, no?

I'm leaning towards a GC-based design that relies a lot on value types.

That sounds good.

Compacting GC makes locality less of a problem than one that would think with the old Java/Haskell style, but yes we in Haskell also want unboxed types (the name I prefer) to have more control.

In cases where if one traverses the parent they almost certainly traverse the child (e.g. from map nodes to their keys (not child maps nodes) they area good fit, as with long live objects.

----

The overall lesson here is that Haskell/Java programs can be surprising fast and not memory thrashing, but for reasons that are quite surprising. Two Haskell and Rust programs can feel similar in what they mean and how they are written, but then be fast for very, very different reasons.

throwaway34241• 5 years ago

Being able to have many GCs is a good thing.

The only advantage I can think of to having a single GC is with using 3rd party packages. If the trade off is always low latency and throughput then libraries know to target that when optimizing, otherwise it’s less clear what to benchmark with.

hashmash2• 5 years ago

The author doesn't really understand how Java escape analysis works, and just focuses on one key aspect: "It does not replace a heap allocation with a stack allocation for objects that do not globally escape."

The author then implies that escape analysis is only used to reduce lock acquisition. Java escape analysis will replace a heap allocation with a stack allocation if the code is fully inlined. This is known as scalar replacement.

aktau• 5 years ago

I don't know much about this, but upthread various people say that scalar replacement happens very rarely if at all, currently. E.g.: https://news.ycombinator.com/item?id=29324132.

Could you perhaps comment on that, since you seem to have experience?

pjmlp12• 5 years ago

First of all that blog post is wrong, it uses Optional which isn't a value type to start with, and contains internal fields.

It is considered a value like class, that will eventually be turned into a value type when Valhala arrives, until then there are no guarantees in scalar replacement.

Secondly, GraalVM or Azul are much better at it, which the author didn't bother to try their blog post on.

native_samples6• 5 years ago

The issue is not that it doesn't happen - it does, all the time. The problem is it's unpredictable, hard to control and hard to measure. So it's sort of magic that gets blurred into all the other optimizations the VM is doing, and refactoring your code can make the difference between it happening or not.

dragontamer2• 5 years ago

In a multithreaded program, a bump allocator requires locks. That kills their performance advantage.

Wait, what?

What's wrong with:

    char theHeap[0x1000000];
    atomic_ulong bumpPtr;

    void* bump_malloc(int size){
        uint32_t returnCandidate = bumpPtr.fetch_add(size, std::memory_order_relaxed); 
        if(returnCandidate + size >= HEAP_SIZE){
            // Garbage collect. Super complicated, lets ignore it lol.
            // Once garbage collect is done, try to malloc again. If fail then panic().
        }
        return &theHeap[returnCandidate];
    }

------

You don't even need acq_release consistency here, as far as I can tell. Even purely relaxed memory ordering seems to work, which means you definitely don't need locks or even memory barriers.

The exception is maybe the garbage-collect routine. Locking for garbage collect is probably reasonable (other programmers accept that garbage-collection is heavy and may incur a large running + synchronization costs), but keeping locks outside of the "hot path" is the goal.

------

This is what I do with my GPU test programs, where locking is a very, very bad idea (but possible to do). Even atomics are kinda-bad in the GPU world but relaxed-atomics are quite fast.

-------

In Java, this requires 15 000 separate allocations, each producing a separate reference that must be managed.

Wait, what?

    points [] array = new points[15000];

This is a singular alloc in Java. 15000 _constructors_ will be called IIRC (My Java is rusty though, someone double-check me on that), but that's not the same as 15000 allocs being called, not by a long shot.

------

Frankly, it seems like this poster is reasonably good at understanding Go performance, but doesn't seem to know much about Java performance or implementations.

GreenToad• 5 years ago

    Point[] array=new Point[15000];

In java would create an array with null references, to fill it up you need to create each object so that point is valid.

dragontamer2• 5 years ago

I stand corrected on that point.

comex• 5 years ago

Even with relaxed memory ordering, you’re still bouncing the cache line around between every CPU that tries to access bumpPtr. I would expect that to be significantly slower than using per-thread heaps (especially if you have a large number of CPUs).

haimez• 5 years ago

Java bump pointer allocations (ie: normal allocations, except for eg: large array allocations) occur in a thread local allocation buffer. Only when a thread exhausts its current allocation buffer does it need to worry about potentially contending with other threads to acquire a new one.

esarbe• 5 years ago

Java is a language that basically outsourced memory management entirely to its garbage collector. This turned out to be a big mistake.

Given that Java is not far behind C and C++ for many kinds of workload and in quite some scenarios can outperform C code, I'm not sure that I buy this line of reasoning.

Doing these updates requires freezing all threads.

Eh, what? There are multi-threaded GCs, what is this article even talking about?

However, this does not put C# and Java on equal footing with languages like Go and C/C++ in terms of memory management flexibility

In which world are Go and C in the same worlds when it comes to memory management flexibility? That's like comparing a language that uses a Garbage Collector to one that requires manual memory management. Because - it is.

Modern Languages Don’t Need Compacting GCs
If need be, the Pacer slows down allocation while speeding up marking.

So, you just traded in one drawback for another?

Heck, I get it. The JVM is not a thin graceful fawn. It's a complicated beast that requires years of experience to tame it - and even then it will come back from time to time an bite you. There are many good points to critique the JVM - but I don't get the feeling that the author of this article has spent much time with modern JVMs because he's not pointing out any of them.

maxpert• 5 years ago

Low Java knowledge and more Fan babel rather than true critique.

dandotway4• 5 years ago

The binary-trees benchmark on The Debian Language Shootout[1] involves allocating millions of short-lived trees and traversing them. It is informative about GC performance even with the caveat that there are 'lies, damned lies, and benchmarks', because many real-world graph analysis and brute force tree search algorithms similarly allocate zillions of short-lived nodes. For non-GC languages like C/C++/Rust it gives a decent idea of the performance difference between malloc'ing and freeing individual objects vs doing bulk arena allocations:

  language         secs       GC'd language?
  ========         ====       ==============
  C++ (g++)        0.94
  Rust             1.09
  C (gcc)          1.54
  Free Pascal      1.99
  Intel Fortran    2.38
  Java             2.48       yes  <====
  Lisp (SBCL)      2.84       yes
  Ada (GNAT)       3.12
  OCaml            4.68       yes
  Racket           4.81       yes
  C# .NET          4.81       yes
  Haskell (GHC)    5.02       yes
  Erlang           5.19       yes
  F# .NET          6.06       yes
  Node.js          7.20       yes
  Julia            7.43       yes
  Chapel           7.96       yes
  Dart             9.90       yes
  Go              12.23       yes  <====
  Swift           16.15       * "Automatic Reference Counting"
  Smalltalk (VW)  16.33       yes
  PHP             18.64       yes
  Ruby            23.80       yes
  Python 3        48.03       yes
  Lua             48.15       yes
  Perl            53.02       yes

So Java has the fastest GC for this test, 2.48 secs vs 12.23 secs for Golang. The Java code is also notably perfectly idiomatic for multicore, it doesn't do heroic "avoid GC by writing C-like code manipulating a fixed global memory array" tricks. The Java code is also more concise.

The 'plain C' code that uses Apache Portable Runtime memory pools instead of standard malloc/free and uses OpenMP #pragma's strikes me as more 'heroic' than 'idiomatic', whereas C++ and Rust use standard libraries/crates and idiomatic patterns. (Note that OpenMP is 'standard' for high-performance C and well supported across GCC/LLVM/Microsoft/Intel compilers. But still....)

OCaml and Haskell made impressive showings for functional languages which are in practice the easiest for dealing with complicated tree algorithms, which is perhaps why the formally verified C compiler, CompCert, is implemented in OCaml, as is Frama-C for formally verifying ISO C programs, as is the Coq theorem prover, etc.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [Edited link]

geodel14• 5 years ago

So Java has the fastest GC for this test, 2.48 secs vs 12.23 secs for Golang.

Further not mentioning memory used Java/Go programs makes it very fair comparison. Because GC perf does not depend on memory allocated.

dandotway4• 5 years ago

Right now in the datacenter CPU usage is considerably more expensive than RAM usage. Ram consumes comparatively little power, whereas burning hot CPUs+GPUs are the reason datacenters are favored near cooling water and power stations. 2.48 vs 12.23 seconds for Java and Go is a big deal for how many solar panels or tons of coal are needed to run an app on Xeon or Epyc instances, whereas 1.7GB vs 0.4GB for Java and Go, a 4x difference in low-power memory usage, is not so big of deal.

At any rate I did link to the full table so everyone can see the mem usage, source listings, etc.

tossaway326• 5 years ago

Look at the Go benchmark program:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Needs to be faster? Use a pool like the C benchmark programs, but super simple: just a slice, local to the goroutine.

Trivially make the Go program 10x faster, 5 minutes of work, a few edits:

  type Tree struct {
          Left  int
          Right int
  }

  func itemCheck(id int, pool []Tree) uint32 {
          tree := &pool[id]
          if tree.Left != -1 && tree.Right != -1 {
                  return uint32(1) + itemCheck(tree.Right, pool) + itemCheck(tree.Left, pool)
          }
          return 1
  }

  func bottomUpTree(depth uint32, pool *[]Tree) int {
          var tree Tree
          if depth > uint32(0) {
                  tree.Left = bottomUpTree(depth-1, pool)
                  tree.Right = bottomUpTree(depth-1, pool)
          } else {
                  tree.Left = -1
                  tree.Right = -1
          }
          id := len(*pool)
          *pool = append(*pool, tree)
          return id
  }

  func inner(depth, iterations uint32) string {
          var (
                  pool []Tree
                  chk  = uint32(0)
          )
          for i := uint32(0); i < iterations; i++ {
                  a := bottomUpTree(depth, &pool)
                  chk += itemCheck(a, pool)
                  pool = pool[:0]
          }
          return fmt.Sprintf("%d\t trees of depth %d\t check: %d",
                  iterations, depth, chk)
  }

If it matters, your Go program can be made as fast as a C program.

Easily.

dandotway4• 5 years ago

Would you mind posting a complete example that compiles and runs? Your above changes to Go#8 break it. E.g. the function 'run' needs to be updated to use your new 'bottomUpTree' and 'inner'.

sigmaml2• 5 years ago

Several (about 10) years ago, I submitted essentially the same program. It was one of the fastest of all the implementations across all the languages.

However, Isaac rejected it, saying it violated the conditions.

azth8• 5 years ago

Now do the same in Java and it will be as fast, if not faster. The point is the benchmark is looking at GC performance. In large real world programs, it is not trivial to make such changes.

kazinator• 5 years ago

We can't say that this is a purely GC benchmark. Generating and checking these trees takes time independently of garbage collection. Without a detailed report from the programming language run-time about how much time was spent in GC, it's just a guess.

madmax108• 5 years ago

As some of the other comments in the thread allude, this is quite a rudimentary (or rather outdated) understanding of how Java GC operates and ends up (unfortunately) turning an otherwise good comparison into a straw-man argument.

As someone who's worked with Java from the days where "If you want superhigh performance from Java without GC pauses, then just turn off GC and restart your process every X hours" was considered a "valid" way to run high-performance Java systems, I think the changes Java has made to GC are among the biggest improvements to the framework/JVM and have contributed vastly to JVM stability and growth over the last decade.

geodel14• 5 years ago

Fundamentals of Java about data/class layouts in memory have remain same for decades. So author is right at big picture.

I think the changes Java has made to GC are among the biggest improvements to the framework/JVM and have contributed vastly to JVM stability and growth over the last decade.

This is of course true. However the point is for Java it is absolute necessity for Go it may be nice to have.

pjmlp12• 5 years ago

I guess it is the same reasoning like Go not needing generics.

geodel14• 5 years ago

No, it is same reasoning as Java not needing dense memory layouts

kaba011• 5 years ago

Work on Valhalla is not funded as a joke though. They are working on that one.

pjmlp12• 5 years ago

No, Java folks never denied they were eventually needed, in fact IBM has had the object layout extension on their implementation for almost a decade now.

gwbas1c2• 5 years ago

Skimmed this and found that a lot of claims are inaccurate and don't have data... Then realized, ugh, it's another Medium post. One particular wrong claim:

In C#, for example, reference objects and value objects live entirely separate lives. Value objects are always passed by value. You cannot take the the address of a value object and pass that around. No, you need to copy the whole object every time.

In C#, there are normal, C-style pointers. (Although they aren't used very often, mostly when interoperating with C APIs.) Furthermore, you can pass a struct by reference if copying the struct is a problem.

I once wrote some performance critical code where I used structs and past them around by pointers. I ran the code through a profiler, and then refactored to use normal idiomatic non-pointer code. After running through a profiler there was no performance difference.

---

The author of this post really needs to base their claims on actual data. Some well-tuned programs in the languages compared and then compare the performance.

sitkack4• 5 years ago

In general when talking about quantitative subjects, we need to use quantitative measures. I think the author is nearly there, but in general, unless you have data to refute your claims, it should be ignored. I don't say this snarkely, but in a domain where we actually have hard quantitative measures, they should be used and required for argument.

WatchDog• 5 years ago

Quantitative measures would be nice, but I would imagine that it's going to be really difficult to quantitatively compare go and java garbage collectors, without a billion other factors about the language/runtime getting in the way.

joelfolksy3• 5 years ago

Yep. His claims about C# are so egregiously wrong that the entire piece can safely be dismissed.

jayd162• 5 years ago

Did Go ever fix that problem where short term high memory usage can cause large empty heaps because of the lack of compaction?

I remember a rash of articles about this phenomena a while back. This article seems to think its not an issue so I'm wondering when it was fixed.

jatone9• 5 years ago

that was never an issue? maybe your thinking of the slowness golang had in returning memory to the OS? that was resolved.

Jweb_Guru2• 5 years ago

No, it was never fixed and probably never will be, because it would make Go perform worse in the latency-sensitive microbenchmarks it wants to do well in.

netheril96• 5 years ago

Go may have less need of an advanced GC, but surely it could only get faster if it had a Java-like GC.

phonicwheel• 5 years ago

Headline follows logically from "Does not need Go"

DeathArrow2• 5 years ago

Lots of flaws in the article. Rust doesn't need a Java like GC because Rust doesn't have a need for GC. C# has pointers. "Old" languages like C and C++ also don't need a Java like GC, so it's not something related to "modern" languages.

DeathArrow2• 5 years ago

I like how memory management is done in Nim [1]. You can chose among several garbage collectors, manual memory management or no memory management at all, depending on what better fits your use case.

[1] https://nim-lang.org/docs/gc.html

winrid• 5 years ago

The default memory manager also won't do any stop the world pauses due to the way that cross thread communication works.

That's not to say the latest Java GCs aren't incredibly impressive - they are.

azth8• 5 years ago

Modern languages such as Go,

golang is modern? it's stuck in the 70's

azth8• 5 years ago

In C#, for example, reference objects and value objects live entirely separate lives. Value objects are always passed by value. *You cannot take the the address of a value object and pass that around.*

The last sentence is wrong. You can pass structs by ref in C# (ref, in, out parameters). Java will also allow taking references to value types and passing them.

joelfolksy3• 5 years ago

Is there a single statement about C# in this piece that isn't a complete falsehood?

pipeline_peak• 5 years ago

What exactly does Go solve that can’t be done in C#?

SureshG2• 5 years ago

jfyi: here is the latency GC numbers (JDK17) - https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html . The experience is vastly different compared to an 8 year old jdk version (jdk 8)

p5v• 5 years ago

It’s an insightful article, but I can’t get around the fact that almost every paragraph contains subtle typos. Makes me wonder, whether the author bothered to do a final pass on the text, or just dumped everything out of his mind, and hit Publish.

rbetts• 5 years ago

Or maybe isn't a native English speaker and did a wonderful job in a second language?

Go does not need a Java-style GC

Related Stories