1. 13
  1. 3

    The soft memory limit is a Good Thing for ergonomics. What a lot of users need is “keep my service under X GB of RAM use” but GOGC only let you tell the runtime “let my service use up to Y times the data left after last GC.”

    The other end of this problem is that if you have have much live data but allocate fast, the “collect at 2x live heap size” default could spend CPU saving a fraction of a percent of your memory when that might not be the most practical thing for you (relevant 2017 and 2019 posts). In Java they apparently have the greater of 1/64 of RAM an a hardcoded value as the minimum heap size to deal with this. I’m not sure if Go has changed anything on that end since those old posts.

    1. 1

      Sigh, typo here inverted my meaning:

      if you have have much live data but allocate fast

      If you don’t have much live data but allocate fast, the default GC policies could make the wrong CPU/RAM tradeoff for you.

    2. 3

      Go 1.19 supports the Loongson 64-bit architecture LoongArch on Linux (GOOS=linux, GOARCH=loong64).

      Interesting, I thought loongson was just an x86 clone. I wonder how they do automated testing for this too. It didn’t seem like I could get any loongson SoCs/dev boards last time I looked. But the Go team is better connected than I am…

      1. 1

        Loongson has always been a MIPS derivative AFAIK.

        1. 1

          Oh yeah you’re right. Either way I thought it was just a clone. But I guess it differs enough from MIPS that they needed a new architecture to represent it in Go.

      2. 2

        The Go memory model has been revised to align Go with the memory model used by C, C++, Java, JavaScript, Rust, and Swift.

        Does this improve Go’s C interoperability?

        1. 5

          No, I think it mostly just formalizes what the compiler has already been doing the whole time. The difficulty with C interoperability has always been due to the runtime: switching from goroutines with small stacks to a thread with a large enough stack for C code to safely run, and the garbage collector always needing precise information about what memory locations contain reachable pointers into the Go managed heap to track and potentially update.

          https://research.swtch.com/mm is a great series of articles on the work that was done.