
Go memory ballast: How I learnt to stop worrying and love the heap - _ILLuMiNatus_
https://blog.twitch.tv/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2
======
cyrusaf
Great article! I found the section on "GC Assists" very informative:

> You can think of this like a tax that your goroutine must pay for allocating
> during a GC cycle, except that this tax must be paid upfront before the
> allocation can actually happen.

------
gfs
From this presentation [0] a while ago, I remember reading this quote:

> We also do not intend to increase the GC API surface. We've had almost a
> decade now and we have two knobs and that feels about right. There is not an
> application that is important enough for us to add a new flag.

I would expect that creating "tuning knobs" for garbage collection is a
complex task. Managing the garbage collector seems like it really differs
across applications. Is this why the Go team hasn't added any more ability to
adjust how the garbage collector runs?

[0]:
[https://blog.golang.org/ismmkeynote](https://blog.golang.org/ismmkeynote)

------
rengers
Author here, happy to answer questions.

------
apta
All these hacks to get around what something like the JVM or .NET already
expose as tunable parameters. Yet somehow the golang proponents still claim
that the golang environment is somehow "better".

~~~
spenczar5
Are tunable parameters necessarily better? A system with more options puts the
onus on the operator to get things right, which means many JVM applications
need to be individually tuned.

If an autopilot can be done well, it's much better. This article reveals a
spot where Go's autopilot goes haywire, but the general typical experience is
much better than this.

~~~
apta
When you're looking for getting the most out of your system, then yes. The JVM
has reasonable defaults, and has recently switched its default GC to lower
latency numbers at the expense of throughput (which golang already does, but
it only has a single GC). The JVMs newer GCs also have fewer parameters to
tune, by nature of what they do.

The JVM already runs on systems with 100s of GB and more (even TBs). golang
will have issues running on such systems.

------
nightseeker
It’s not often I come across a well-written post by an engineer. This one is
remarkably clear.

