Paul Rubin <no.email@nospam.invalid>: > Note that Java has a lot of [GC] options to choose from: > https://docs.oracle.com/javase/9/gctuning/available-collectors.htm
I'm all for GC, but Java's GC tuning options are the strongest counter-argument against it. The options just shift the blame from the programming language to the operator of the software. For GC to be acceptable, you shouldn't ever have to tune it. And I've seen it in action. A customer complains about bad performance. The system engineer makes a tailored GC recipe to address the issue, which may help for a short while. Here's my rule of thumb. Calculate how much memory you need for long-term objects. Don't let the application exceed that amount. Multiply the amount by 10 and allocate that much RAM for your application. > Another approach is Erlang's, where the application is split into a > lot of small lightweight processes, each of which has its own GC and > heap. So while some of them are GC'ing, the rest can keep running. So the lightweight processes don't share any data. That may be a fine approach. Marko -- https://mail.python.org/mailman/listinfo/python-list
