[nickbauman]

Yes; I have a friend who is part of a small team that wrote a very successful stock market trading gateway in Java. Turns out the JVM's GC can be tuned in very specific ways based on your needs. And there are ways to avoid having to do JVM GC in critical areas of the code as well.

[jonas21]

> And there are ways to avoid having to do JVM GC in critical areas of the code as well.

Yeah, you allocate a large pool of objects up front and manually reference count them. Every high-performance Java application I've seen ends up doing this. But isn't that an argument for reference counting?

[kgeist]

>Yeah, you allocate a large pool of objects up front and manually reference count them. Every high-performance Java application I've seen ends up doing this

Not sure if it's still relevant, though.

One popular physics library years ago went as far as instrumenting compiled bytecode to turn all vector/matrix allocations to fetching preallocated objects from a pool, because a simple math operation could allocate tens/hundreds of vector/matrix objects and GC was slow, but then in newer versions they removed it because Java's GC became fast enough.

[pjmlp]

It is an argument that Java can do arenas like some other languages, while providing the productivity of a tracing GC for the rest of the non critical path code.

[PaulHoule]

Generally Java has made a huge investment in the garbage collector over a long period of time to address the problems that people have in some use cases. JDK 17 is much better than JDK 8. If you were writing a GC from scratch you are not going to do as well.

[hinkley]

To be fair, they definitely got into a rut in the JDK 6-7 timeframe. I maintain it's no accident that memcache came into its own during this period. That was a major pain point, and going out-of-process shouldn't have been necessary.

[bcrosby95]

I always figured memcached gained popularity because it let your monolithic LAMP-like-stack scale better, not because of anything about Java. Just wedge it between your N stateless application servers and MySQL and you could handle 10x more users.

At least, that's how most people I knew back in 2006ish were using it.

[hinkley]

I think each ecosystem had a very different experience with memcached adoption. In Java it was really limiting to do in process cache, and that limitation hit a wall while memcached usage was starting to spread. I assume Rails and maybe Python had similar problems, because all of the papers about GC techniques up to about that point were talking about Java. They got a lot of good stuff first or second.

What’s common though is that hard drives were not getting faster, but network hardware was hitting its stride. Full bandwidth (port speed X port count) routers and multi NIC were recently ubiquitous.

I had just come off a carrier grade software project when memcached finally hit my radar, and we had only spec’ed 3-5 servers for the web tier. That was still enough local cache hit rate to keep us running relatively smoothly. Or at least once we got done being honorary QA members for F5. We had lots of problems on that project with data modeling and so we actually were using too much caching vs precalculation but that’s a different story.

[marginalia_nu]

There's several exchanges and clearing platforms running Java[1], although I'm not sure how many are still around after Nasdaq's hostile takeover.

[1] https://www.marketswiki.com/wiki/TRADExpress

[kaba0]

The JVM GC’s are absolutely insanely good. G1 can sustain loads with heap sizes well into TERAbytes.

[viktorcode]

As I heard those guys write allocation-free Java code in critical paths. Nothing allocated, nothing to collect.