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