JVM apparently has the disadvantage that nobody under the age of 40 wants to touch it anymore. I admit I haven't worked in it in 20 years, but I do think it's a marvel of engineering and unfairly maligned. It used to be my career but I wanted to be closer to the metal.
Having Oracle's tramp-stamp on it may have been the final kiss of death in terms of totally-superficial "coolness" factor.
The JVM has a fixed size heap which for me it is wasteful.
IMHO, Microsoft made the correct approach on .NET.
For LLMs, I prefer C# and C++ instead of TypeScript, JavaScript or Python as the static + compiled language factor keeps the coding agents on track. Plus, they have a true threading/async implementation.
It's only appearing wasteful if you're not understanding how memory management works on modern operating systems. It's not wasting any RAM at all if you pay attention to RSS vs VSS.
The actual physical RAM is still entirely available to other applications. It's just made the OS know it might want that many pages. Until there's data in the pages, they will not count towards total RSS.
It's the kind of things some sysadmins used to gripe to me about and I would question whether they should be in charge of a machine at all.
To repeat: just because an application mmaps a large region doesn't mean the OS has actually given it all that physical RAM. It's merely made sure the pagetable knows about it.
I know how mmap works. The JVM is/was terrible on freeing allocated memory though.
If the program is actively using that allocation, that's fine. My problem is with the runtime hoarding RAM when it should have been freed after GC back to the OS.
Then there's also the JVM not handling peaks well because it hit the max heap size, while you still could rely on the OS doing its job to shuffle stuff to swap temporarily. I still see JVM OOMs in my $dayjob's product while the OS has plenty of free physical memory. It is stupid.
I mean, we have malloc() and free(), they are in the stdlib for a reason :)
The JVM seems to follow a philosophy where it assumes it is the only process running besides PID 1, which is valid for some scenarios, but not for others.
Well, you either spend energy freeing stuff or you waste some memory. It's a tradeoff, that you can trivially set with a single flag in Java.
In pretty much every other runtime's case you are stuck with whatever their GC uses, and almost every other GC is far less advanced than the JVM's implementationS. And manual memory management is not free of tradeoffs either, e.g. RAII can have pretty long destruct chains in both C++ and Rust.
Even when I was at Google (2011-2021) it was slowly falling out of favour and by the time I left, Go was fairly rapidly taking its place as the "garbage collected managed language" choice.
Not saying that's a good or a bad thing. I still think the JVM is remarkable.
and you could say the same if not better from C#. But those are now becoming niche languages and ecosystems. One for people around microsoft, azure, etc. The other around oracle solutions. There are still pretty interesting projects around it any of them, but they seem to be losing mindshare against other languages.
Having Oracle's tramp-stamp on it may have been the final kiss of death in terms of totally-superficial "coolness" factor.