Maybe, but that just raises the question...If you're coding your system under the constraint that you should not be having any GC-event, what's the point of picking a GC language in the first place?
As others said, no full GC events. Young generation GC is cheap, no need to avoid that.
Productivity is the point. Even while paying attention to GC, it's much faster to write good code in Java than to worry about every malloc() in C. I love C, but if I need to churn out high performance code quickly, Java is the choice.
But here we're talking about C++: you don't write malloc, you use containers that encapsulate memory management - likely std::containers with pool allocators. And you put things on the stack. Code is as readable if not more than java - there isn't any "new," anywhere in sight
C++ after 11 is a very different beast. It's more pleasant to write compared with pre-11. Memory model, move semantics, smart pointers, lots of stuff standardized instead of left to the libraries.
smart pointer template blah, instead of pointer blah, in a very large code base.. hmm not so pleasant.. the debug level function definitions, adding templated parameters, are literally unreadable. I will agree that the mental model is tamer.
GP was not talking about "any GC-event", but about "any full GC (pause) events". That's where the heap has gotten so messy that everything has to stop while the GC sorts it out. It's an absolute worst case scenario. Under normal conditions on a modern JVM, the GC runs in parallel with the application and does not cause any pauses.
They said no full GC. The GC runs constantly in parallel with your program and cleans up what it can, but never has to pause execution of the whole program to reclaim even more memory. Not claiming I know how to do this, but I believe this is what they claiming.
Well, the first place may have predated you and a rewrite is out of the question.
A few other reasons:
The rest of the platform for review and analysis doesn’t have such stringent performance requirements and it would be nice to reuse code.
There also may be some good libraries that are jvm only that your program relies on.
Packing up a fat jar can be a lot easier, less complex and more reliable than building a binary.
Your dev team has a lot Java expertise.
Getting Java to not allocate is not as hard as it seems if you set out to do it from the start. And even if not it’s not impossible because the tooling is so good. You just have to know the right tricks and it can be easier to incrementally learn those tricks for a dev team than learn C++ and it’s ecosystem.
