4 ms·

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

by jokoon 3y ago

jeeyoungk 3y ago
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.
- 0cf8612b2e1e 3y ago
  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.
  - hbn 3y ago
    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
  - titzer 3y ago
    > 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.
    - 0cf8612b2e1e 3y ago
      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=98125 https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...
    - ilyt 3y ago
      Nobody said it was good missile.
rsc 3y ago
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.
- ash_gti 3y ago
  If you have a short lived CLI tool, disabling the GC might be useful but that’s likely an exceptional case.
- 015a 3y ago
  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.
  - coder543 3y ago
    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.
    - cratermoon 3y ago
      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?
llimllib 3y ago
https://go.dev/doc/gc-guide 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
oefrha 3y ago
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.
- throwaway894345 3y ago
  If you're definitely not allocating on the heap, setting GOGC=off should make no difference, right?
- _ph_ 3y ago
  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.
bheadmaster 3y ago
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.
- throwaway894345 3y ago
  > 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?
  - bheadmaster 3y ago
    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.
  - wahern 3y ago
    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.
    - throwaway894345 3y ago
ainar-g 3y ago
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_Developing_Safety-Critical_Code https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...
- throwaway894345 3y ago
  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?
  - ainar-g 3y ago
    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.
aatd86 3y ago
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.
ilyt 3y ago
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).

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

by jokoon 3y ago

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 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.

0cf8612b2e1e 3y ago
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.
- hbn 3y ago
  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
- titzer 3y ago
  > 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.
  - 0cf8612b2e1e 3y ago
    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=98125 https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...
  - ilyt 3y ago
    Nobody said it was good missile.

rsc 3y ago

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.

ash_gti 3y ago
If you have a short lived CLI tool, disabling the GC might be useful but that’s likely an exceptional case.
015a 3y ago
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.
- coder543 3y ago
  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.
  - cratermoon 3y ago
    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?

llimllib 3y ago

https://go.dev/doc/gc-guide 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

oefrha 3y ago

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.

throwaway894345 3y ago
If you're definitely not allocating on the heap, setting GOGC=off should make no difference, right?
_ph_ 3y ago
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.

bheadmaster 3y ago

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.

throwaway894345 3y ago
> 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?
- bheadmaster 3y ago
  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.
- wahern 3y ago
  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.
  - throwaway894345 3y ago

ainar-g 3y ago

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_Developing_Safety-Critical_Code https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...

throwaway894345 3y ago
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?
- ainar-g 3y ago
  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.

aatd86 3y ago

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.

ilyt 3y ago

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).