6 ms·

For Go and/or C# lambda support would it be worth even running the garbage collector, or just allocating a block of memory and cleaning it up when the function

• jitl 9y ago
  We do this during request execution in our Ruby services. We tell the GC to pre-allocate a few GBs of memory, and then explicitly suspend GC until the end of the request. Then we do a single GC run.
  • wickawic 9y ago
    Very interesting! Have you experienced improvements from this approach?
    • jitl 9y ago
      Absolutely. It's a critical part of our runtime configuration, but we're hardly the first people to think of this approach. I remember reading some discussion in an HN thread about FinTech developers who run Java with 100GB+ heaps and no garbage collector, and then reboot the application after the markets close. I can't find that specific thread, but I did find this which has a few nuggets on the same subject: https://news.ycombinator.com/item?id=6131786 https://news.ycombinator.com/item?id=6131786
      • jnordwick 9y ago
        While that does happen sometimes, from where I've worked at it is more common to write in a garbage-less style (basically not allocating or pooling everything) since JIT time matters at startup, especially for certain classes of strategies. Ive seen applications run and never GC after initial startup until they get bounced to update. Another problem with the big heap is that you still have tlab issues if you keep allocating. There is a new-ish poc collector called the null collector that literally does nothing, not even instrumentation, i believe, of write barriers. We always see idiomatic programs benched against each other but I'd really like to see high performance pure java against high performance pure go and others. Some of the low latency Java tricks we use I'm not sure if they can even be copied in other hll (not including c/c++).
        • wging 9y ago
          do you mean Epsilon? https://bugs.openjdk.java.net/browse/JDK-8174901 https://bugs.openjdk.java.net/browse/JDK-8174901
          • jnordwick 9y ago
            That's it. I was looking all over for it. Thanks.
    • ignoramous 9y ago
      > Very interesting! Yep. There's a proposal by a couple of folks to get this implemented in the Golang runtime. The feature is aptly named 'Request Oriented GC'. https://news.ycombinator.com/item?id=11969740 https://news.ycombinator.com/item?id=11969740
• elwesties 9y ago
  This is an interesting question. I think it depends on the situation, You pay for memory so if you are getting near the cap in the execution of your function then managing the memory as you go may be beneficial but otherwise I don't see why you wouldn't just ignore it. I do have an open question weather the memory leak would effect subsequent runs of the function after it has been "warmed up" - https://serverless.com/blog/keep-your-lambdas-warm/ https://serverless.com/blog/keep-your-lambdas-warm/.
• brianwawok 9y ago
  Most lambdas would be reused many times, the use once and kill the VM is not the only plan...
• eklavya 9y ago
  I think that's arena allocation and that's what compact regions do in haskell.
• sudhirj 9y ago
  Generally an interesting idea, but Lambda containers are re-used across requests, so might not be a good thing to do in this case. If there's no reuse, and they figure out sub millisecond cold start, they could do this and essentially create a disposable server for each request. Ironically, I think that's what CGI did :D
• gizzlon 9y ago
  Not needed for Go (IMHO) since any delay caused by GC pausing (1ms? 7ms?) will drown in the time it takes to make a network call. https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/ https://making.pusher.com/golangs-real-time-gc-in-theory-and...
• scarhill 9y ago
  Lambda containers can run for hours at a time. It doesn't just fork a new process for every request: https://docs.aws.amazon.com/lambda/latest/dg/running-lambda-code.html https://docs.aws.amazon.com/lambda/latest/dg/running-lambda-...