Rather than offer tens of different arguements for setting different levels of memory utilisation, start points, maximums, and different algorithm choices, and then expecting the customer to tweak, tune and test against this until they're as happy as they can get, it is suggested that it be possible to set a small number of parameters describing the type of performance you want, and have the JVM tune itself on the fly to try to match that. Having the JVM work with heuristics to tune itself would be considerably easier than the long test-environment effort that is currently necessary for large applications.

So for instance you might start the JVM stating that you wanted it to try to keep FullGCs below 0.3 seconds, and/or keep total memory utilisation below 300M. It would then take an educated guess at the requirements for its initial resources, and at each GC would examine how well it did compared to these settings, and re-tune accordingly.

While it is understood that this can't be an exact science - there *can't* be a guarantee that a GC won't take over a set time limit should a number of "popular objects" occur, for which a large number of references need to be updated when it's moved - this is also true of the hard-searched for customer-configured tuning scenario, only without the hours of sucking-to-see the customer must originally go through to get to this point for every deployment on every different hardware platform.