On Friday 07 July 2017 03:26 AM, Eliot Miranda wrote:
Let's say that currently the mark-compact collector collects at about 1Gb per second (that's about what I'm seeing on my MacMini for a 600Mb heap, collected and compacted in about 530ms on a 2.3GHz Core i7, = 1.1Gb/s). For the moment let's assume the GC scales linearly. Then a 10Gb server application will occasionally suffer 10 second pauses, which is unacceptable for any kind of high-availability server. The total execution time overhead of GC may be in the 1%-10% range, but the pause times may be unacceptable (note that they're /not/ unacceptable for my employer's batch usage).
Good point! Object memory is a shared resource and like any shared resource will eventually become a bottleneck as it grows. We could also tackle the problem of large apps with a different approach. The overheads of VM process may become negligible enough to make message passing across multiple co-operating processes more efficient than within a large monolithic process. E.g. if a computation of 1GB of data generates 10GB of garbage, then the extra 10GB need not be explicitly garbage collected if the task is done in a child (worker) process and terminated after the computed result is passed back to its parent. Regards .. Subbu