Hacker News new | ask | show | jobs
by PaulHoule 1421 days ago
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.
1 comments

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

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.