[pixie_]

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 ends?

Side note I think that should be an option for web servers as well for languages with managed memory. Light isolated non-threaded api endpoints shouldn't be interrupted by garbage collection.

[jitl]

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]

Very interesting! Have you experienced improvements from this approach?

[jitl]

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

[jnordwick]

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]

do you mean Epsilon? https://bugs.openjdk.java.net/browse/JDK-8174901

[jnordwick]

That's it. I was looking all over for it. Thanks.

[ignoramous]

> 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

[gizzlon]

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

[sudhirj]

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

[elwesties]

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

[scarhill]

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

[brianwawok]

Most lambdas would be reused many times, the use once and kill the VM is not the only plan...

[eklavya]

I think that's arena allocation and that's what compact regions do in haskell.