_rlh (u/_rlh) - Readit News

_rlh commented on Hyrum’s Law in Golang abenezer.org/blog/hyrum-l... · Posted by u/thunderbong

_rlh · 10 months ago

Fred Brooks discussed this in the unfortunately named pun "The Mythical Man-Month". Most of the gray beards have read it, ask to borrow it, it will make their day. The punchline was on the IBM 360 they stopped fixing bugs when the fix cause the same or more bugs than the unfixed bug, which soon became all bugs.

Well aware of Brooks, when the loop var semantics were changed Go did an analysis showing that many more bugs were fixed than created by the change.

_rlh commented on Conservative GC can be faster than precise GC wingolog.org/archives/202... · Posted by u/diegocg

chrsig · a year ago

It took me a bit to hunt down, but it was part of the go 1.4 release in 2014.

the release notes[0] at the time stated

> The implementation of interface values has been modified. In earlier releases, the interface contained a word that was either a pointer or a one-word scalar value, depending on the type of the concrete object stored. This implementation was problematical for the garbage collector, so as of 1.4 interface values always hold a pointer. In running programs, most interface values were pointers anyway, so the effect is minimal, but programs that store integers (for example) in interfaces will see more allocations.

@rsc wrote in some detail[0] about it the initial layout on his blog.

I couldn't find a detailed explanation about how the optimization interacted w/ the gc, but my understanding is that it couldn't discern between pointer and integer values

[0] https://go.dev/doc/go1.4#runtime [1] https://research.swtch.com/interfaces

_rlh · a year ago

It was a memory model / two word atomicity problem. The mutator uses two writes, one for type and one for value to create the interface. The GC concurrently reads the 2 words of the interface to see if the value is a pointer or not. This is a race that was considered too expensive / complicated to fix.

_rlh commented on Techniques for safe garbage collection in Rust kyju.org/blog/rust-safe-g... · Posted by u/PaulHoule

tsimionescu · a year ago

Those articles claim that these problems don't exist in Go, but they don't really explain why, for many of them.

The one part that is clear indeed is that the pervasive use of value types in Go reduces the amount of garbage that gets generated compared to Java or C#, and, of course, less garbage means less time spent on GC.

The claims about memory fragmentation are less clear though: the first article just says that it's not a problem; and the second one does have a segment dedicated to it, but that segment gets fragmentation completely mixed up with memory locality, an entirely unrelated concept. It later claims that certain allocators are known to not suffer from fragmentation issues, but given the previous confusion, I'm not sure how seriously to take this. It also doesn't say if Go actually uses those allocators or not.

As for the diagnostics, I gave a specific example of a very commonly needed diagnostic, identifying GC roots to understand why a memory leak is occurring, that Go simply doesn't provide (someone else suggested a third party package that might help). I am well aware of the basics provided in the article you linked, and they don't even discuss this. For whatever bizarre reason, the Go memory tools don't provide this info (that the GC obviously needs to determine in its operation) - probably another victim in their quest of making it easier to implement the runtime.

_rlh · a year ago

Go's defrag techniques and why they work are discussed in the Hoard papers and have proven their value not only in Go but in most malloc implementations.

There is a relationship between cache locality, moving colocated objects to different cache lines to control fragmentation, value types, and interior pointers. Perhaps it is subtle but cache optimization is real important for performance and is not ignored by Go in the language spec or the runtime implementation.

_rlh commented on Why is D's garbage collection slower than Go's? forum.dlang.org/post/tjib... · Posted by u/systems

rtfeldman · 3 years ago

> And since there are all kinds of pointers in D, one no longer can use a moving GC allocator, because it cannot know exactly where 100% of the GC pointers are.

I was astonished to learn that researchers found a way to implement a compacting malloc (!!!) by using very clever virtual memory tricks - and which they were able to use to demonstrate memory usage improvements in a long-running Redis instance that used their drop-in malloc replacement:

https://www.youtube.com/watch?v=xb0mVfnvkp0

_rlh · 3 years ago

Still one of the best ideas in the field in recent years. I will note that it also works for non-moving GC collectors and if they are precise, like Go, they can also update pointers and eliminate the redundant page table entries.

_rlh commented on Go does not need a Java-style GC erik-engheim.medium.com/g... · Posted by u/nahuel0x

dandotway · 4 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.

_rlh · 4 years ago

Just for fun set the Java heap to .4 Gigs or use GOGC to set the Go heap to 1.7 Gigs. If Go is faster then try some other sizes and draw a graph to see what the lines look like.

_rlh commented on Erlang Garbage Collection Details and Why It Matters (2015) hamidreza-s.github.io/erl... · Posted by u/jlturner

bluedays · 4 years ago

> *Even if we are using a language that manages memory itself like Erlang, nothing prevents us from understanding how memory is allocated and deallocated. Unlike Go Language Memory Model Documentation Page that advices “If you must read the rest of this document to understand the behavior of your program, you are being too clever. Don’t be clever.”, I believe that we must be clever enough to make our system faster and safer, and sometimes it doesn’t happen unless we dig deeper into what is going on.*

I dunno, article seems right about this. Golang docs sound condescending.

_rlh · 4 years ago

I think you are confusing memory management with memory model. Memory management is about garbage collection, RC, malloc / free, and allocations. Memory models are about what happens when you read and write to shared mutable memory. I'm not a Erlang programmer but in general the Actors concurrency model does not support shared mutable memory. Don't be clever.

_rlh commented on Google’s robots.txt parser is now open source opensource.googleblog.com... · Posted by u/dankohn1

geuszb · 6 years ago

Golang, as a garbage-collected execution environment, suffers from lousy tail latency

_rlh · 6 years ago

Actually Go has the reputation of having solved many runtime problems including the GC tail latency problem.

_rlh commented on Java 12 jdk.java.net/12/... · Posted by u/kalimatas

azhenley · 6 years ago

The most interesting new feature I think is the Shenandoah GC. The summary from [1]:

"Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB."

The original algorithm was published in 2016 [2]. It consists of 4 phases: initial marking, concurrent marking, final marking, and concurrent compaction.

[1] http://openjdk.java.net/jeps/189

[2] https://dl.acm.org/citation.cfm?id=2972210

_rlh · 6 years ago

This thread reads eerily like threads about Go's low latency GC from 2015 and how 10ms isn't good enough and throughput will be impacted and on and on. Three years later Go treats any 500 microsecond pause as a bug as Go continues to focus on throughput. Shenandoah is being put together by some very very smart people and I'm optimistic that the only thing that stands in the way of Java reaching the "500 microseconds is a bug" level is engineering hours and resources. More kudos for this achievement are in order.

_rlh commented on Proposed New Go GC: Transaction-Oriented Collector docs.google.com/document/... · Posted by u/zalmoxes

twotwotwo · 9 years ago

"Transactions" here doesn't mean roll-back-able units like in a database, just small bits of code that terminate (and, the authors hope, leave some garbage behind that you can clean up without scanning a bunch of RAM). Request-oriented collector would have been about as good a name.

This is kind of a spin on generational collection, built around the observation that a lot of Go programs are HTTP/RPC/whatever servers.

_rlh · 9 years ago

Not sure how to reach twotwotwo directly. I was hoping to get permission to rename the GC to ROC from TOC ("request" instead of "transaction"). It's simply a better name and the bird makes for better visuals on the slides. I'm Rick Hudson, rlh@, and can be emailed directly at golang.org.

_rlh commented on Show HN: Mmm – manual memory management for Go github.com/teh-cmc/mmm... · Posted by u/teh_cmc

teh_cmc · 10 years ago

Yes, these benchmarks use forced GC calls (i.e. all phases are STW) because it's the only (good) way I can think of to make theses tests deterministic (maybe you know of a better way? I'd definitely be interested).

Of course, I don't have such calls on production systems; and while concurrent collections greatly reduce the time spent in STW phases, latency spikes are still a very real issue, as I explained here [1]. The monitoring on my production systems leaves absolutly no doubt that those latency spikes are due to garbage collections: once the GC was out of the picture, every thing was flat and fast again.

[1] https://news.ycombinator.com/item?id=10650885

_rlh · 10 years ago

Some folks export GODEBUG=gctrace=1 which will result in the GC dumping out a lot of interesting information including stop the world latency. It doesn't increase the determinism and the GC cycle is started when the runtime decides but it does provide visibility into the concurrent GC latency in a benchmark or actual application. Perhaps you already use it and that is how you noticed the latency problems to start with.

I do know that you need version 1.5 of Go that was released last August to get the low latency GC. If throughput is an issue some folks adjust GOGC to use as much RAM as they can. If none of this helps file an issue report with the Go team. You seem to have a nice well thought out work around but a reproducible gctrace showing hundreds of millisecond of GC latency on heaps with millions of objects will be of interest to the Go team and might really help them.

I hope this helps.