Hacker News Reader

Comment by jokoon | Hacker News Reader

BTW, I've read the Go GC can be disabled, but what happens if you do? Wouldn't you have to avoid memory leaks?

If you turn off the GC then no memory is collected. In general this is not something people actually do. The only time I've ever even seen it mentioned is in an old blog post by ESR, and between him and me, at least one of us didn't understand what he was saying.

If you have a short lived CLI tool, disabling the GC might be useful but that’s likely an exceptional case.

There are popular problem domains where turning off the GC is useful. The best example is Lambda functions/FaaS. Most invocations are short-lived enough that the GC never triggers anyway, but being able to turn it off can help smooth down your P99s where it does trigger, but the world is going to be thrown away in 50 milliseconds anyway. This is a known, not-uncommon performance optimization in other languages on Lambda; but I have less experience using Go on Lambda.

That doesn’t seem like a real thing. Lambda and every other FaaS that I’m aware of will reuse a single instance of the function for multiple invocations. It is not started from scratch with each invocation. Each instance can live for hours, handling a very large number of (sequential) invocations during that time.

If you’re not GCing, you will almost certainly run into OOMs.

If the FaaS can catch the OOM, restart the instance and re-run the request, the visible effect would be somewhat greater latency for that request. If the service is configured to automatically kill and restart instances after some time or some number of requests, it seems like a reasonable tradeoff. Am I missing something?

> If the FaaS can catch the OOM, restart the instance and re-run the request, the visible effect would be somewhat greater latency for that request.

I’m not aware of an FaaS that would hide the OOM… that falls under the “not a real thing” category I mentioned previously. It would just be a failed request, which is a very visible effect.

Would you like to link me to the Lamda docs that say it will automatically retry the request in case of an OOM?

Also consider that code which OOMs will do so unpredictably. It may have completed half of a task, leaving that task in a corrupt state that requires manual intervention from a human to recover from. If everyone wrote fully idempotent code that can somehow skip the already-completed updates and continue where the OOM occurred, this wouldn’t be a problem, but that isn’t what everyone does. This is certainly a large reason why FaaS do not retry requests automatically at all, in most cases.

> If the service is configured to automatically kill and restart instances after some time or some number of requests, it seems like a reasonable tradeoff.

I don’t believe Lambda has any configuration parameters for those things. That’s not how this is meant to work. Lambda will kill the instance when it has been idle for too long, and that’s the primary factor.

You could manually exit the process when your conditions are met, but why? The benefits of turning off the GC are likely to be negligible. This is a lot of complexity for no real gain. It would take some seriously huge gains demonstrated by well-written benchmarks to convince me that any of this is worthwhile for a FaaS function.

Grug would rather fight t-rex.[0]

If you need absolute performance and control over garbage collection, it’s better to just write the lambda in Rust than to try to hack together a solution by turning off the GC and hoping it doesn’t blow up at the wrong moment.

[0]: https://grugbrain.dev/

https://docs.aws.amazon.com/lambda/latest/dg/invocation-retr... Lambda retry docs. I still would strongly not advice intentionally disabling the GC and explicitly said not to above for the same reasons you're concerned.

Glad you generally agree.

From that link, here are two choice quotes that I think are highly relevant:

> When you invoke a function, two types of error can occur. Invocation errors occur when the invocation request is rejected before your function receives it. Function errors occur when your function's code or runtime returns an error.

> […]

> When you invoke a function directly, you determine the strategy for handling errors related to your function code. Lambda does not automatically retry these types of errors on your behalf. To retry, you can manually re-invoke your function, send the failed event to a queue for debugging, or ignore the error. Your function's code might have run completely, partially, or not at all. If you retry, ensure that your function's code can handle the same event multiple times without causing duplicate transactions or other unwanted side effects.

So, it won’t automatically retry if a function is being directly invoked and OOMs, which I believe was the context of my most recent reply.

There are a few limited scenarios where certain AWS services that are invoking a Lambda asynchronously will decide to retry a couple of times, because it assumes that this type of function will be okay to call multiple times with the same input. Definitely not something worth relying on.

It's not even exclusive to GC'd languages. A toy raytracer I've written in the past got notably faster if I just didn't deallocate anything. Memory management is expensive, and for unix-y software that runs on some input and then quits it can be worth it to just let the OS do the cleanup.

Do not do this in AWS lambda or OpenFaas. Lambda processes are reused in "warm" invocations and are only short lived in cold, infrequent use cases (read: once every > 45 minutes). This is useful when the process dies at the end of every request (in which case you're relying on the OS to do the GC for you).

Also things like compilers...which tend to make lots of garbage but the processes are so short lived who really cares? All the memory is getting released in no more than a few seconds, worst case.

Unless you're writing C++...

there is of course one notable use for turning off garbage collection

https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

That seems like something that would eventually cause problem once someone just takes the software already designed and paid for and slaps it onto missile with longer range...

I'm sure all missiles will eventually cause problems for someone, somewhere

It can, by setting GOGC=0 or from within the program. And yes, you would. It's essentially like writing in C, but not being able to call free(); i.e. allocating a fixed amount of resources at the start of the program and work on them. Which is also a recommendation[1] for safety-critical C code made by a NASA person, incidentally, heh.

[1]: https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...

Most of that seems reasonable, but the "do not use function pointers" boggles my mind. I'm pretty sure the alternative is a bunch of conditionals wherever you would otherwise use a function pointer. I've definitely seen some really ugly code written with this axiom which would certainly be a lot cleaner if rewritten to use function pointers. I'm curious if anyone can make a compelling argument against function pointers?

It's in the original:

> […] Similarly, function pointers should be used only if there is a very strong justification for doing so because they can seriously restrict the types of automated checks that code checkers can perform. For example, if function pointers are used, it can become impossible for a tool to prove the absence of recursion, requiring alternate guarantees to make up for this loss in checking power.

In other words, static analysis beats code cleanliness, in this perspective.

If your program is short running, then it may be more efficient to disable GC and let the dying process to take care of it all.

There many tales about programs foregoing any kind of memory collection and relying upon the business process itself to resolve the issue.

My favorite is a missile. Evidently the program leaks memory like crazy. Solution was to determine how much memory would be required for the platform to fly to its farthest possible target + some margin.

Alternatively are stock trading platforms written in Java. Disable the GC entirely because trading hours are only a a limited portion of the day. Restart the program daily.

I like to think the stock market thing is actually the reverse, and they shut it down every night because all the programs that keep it running were written in a memory-leaking tech stack that needs restarting

> My favorite is a missile.

This might be apocryphal, as software for this class of embedded system almost certainly doesn't dynamically allocate anything; probably doesn't even use pools.

I have a friend who works on missile software at a big defense contractor, and they do actually clean up their memory.

I found a source, quoting the quote, so provenance is what it is

> This sparked an interesting memory for me. I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customers chief software engineer said "Of course it leaks". He went on to point out that they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number. They added this much additional memory to the hardware to "support" the leaks. Since the missile will explode when it hits its target or at the end of its flight, the ultimate in garbage collection is performed without programmer intervention.

[0] https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

Nobody said it was good missile.

Go compiler performs escape analysis, which determines whether or not a particular object "escapes" the function it was created in - and if it doesn't, the compiler allocates it on the stack instead of the heap, thereby removing the need for GC.

So, as long as you write Go in malloc-less C-style (which, admittedly, is a non-insignificant restriction), your program will be able to run just fine forever.

> So, as long as you write Go in malloc-less C-style (which, admittedly, is a non-insignificant restriction), your program will be able to run just fine forever.

What happens if you write your Go functions in this malloc-less C style and they have to grow their stack? Doesn't this mean the old stack is now leaked memory?

I see no reason why would de-allocating a stack require action from the garbage collector - afterall, once a goroutine grows its stack and copies the contents of the old stack to the new stack, there aren't any reachable objects left on the old stack, so it can be deallocated without any GC intervention.

But I don't know enough about Go internals to be 100% sure.

The purpose of escape analysis is to avoid situations where other code or data structures could potentially reference stack-allocated memory. IOW, all stack-allocated data is only referenced from the local function invocation frame, presumably using stack relative addressing, but if not at least the scope of pointer updates is substantially narrowed.

Relatedly, unlike languages like Java, Go doesn't have a moving GC--once something is allocated on the heap, the address is fixed.

I'm not sure how realistic it is to code in an entirely malloc-less style in Go, though, given the limited ability to pass references to stack-allocated objects.

Yeah, I think you’re right that stack allocated data can’t be pointed to by the heap. I don’t know what you mean about “the limited ability to pass references to stack allocated objects” though—you can always pass stack allocated references, you just can’t return them (or they will escape to the heap).

A reference can escape not only up, as a return value, but also down, as a function parameter. I'm not sure how sophisticated the static analyzer and inliners are, but escape analysis can only go so far; e.g. stopping at a method call on an interface type for which it cannot discern the concrete implementation. In fact, I believe at least in early Go releases merely passing an object reference as a parameter to a simple leaf function qualified as an escape, forcing a heap allocation.

Note that the decision to force heap allocation is done at compile time, partly because of the semantics of goroutine stack reallocation as the previous poster hinted at. In principle Go could conditionally copy to heap at runtime, but that's just not Go's style of engineering--that's more in the vein of the JVM and similar environments which push more complexity into the runtime rather than compile time. Though maybe it will or has already begun to go down that road.

Yeah, good point--I wasn't thinking about interface types.

https://go.dev/doc/gc-guide is the docs on mucking with the GC, including disabling it.

> Wouldn't you have to avoid memory leaks?

I've not played with it, but I'd expect that every heap allocation would essentially be a memory leak in that mode

If you allocate everything in advance and use free lists, you can probably do it. I believe that it is one of the few ways tinygo handles memory. (so embedded as a use-case)

Note that GC can be triggered manually.

I've had to do that using the wasm target so that I'd only trigger go GC cycles when the browser was idle. Eventually that use-case might disappear as the integration with a garbage-collected wasm gets deeper.

There are at least two cases where GOGC=off could make sense for increasing performance:

1. You know you’re definitely not allocating on the heap;

2. Your workload is bursty and you can simply keep everything until the process dies and memory is released.

If you're definitely not allocating on the heap, setting GOGC=off should make no difference, right?

You might be allocating on the heap, but if you know in advance that the allocated memory never goes out of scope, then switching off the gc is quite reasonable.

You will leak memory when you disable it.

However, you might not care (app running too short), or you might turn it off only temporarily (say time-critical section you don't want to be interrupted by GC).

Reply on news.ycombinator.com