EM4J is tuned to work with long-running Web applications, where the application serves client requests and response times are the critical performance metric. If EM4J is enabled and the host is not over- committed, there is no cost to running EM4J. When you enable EM4J and begin to over-commit memory, client response times should be similar to running your application with fully reserved memory, the difference imperceptible to your users. As the host memory pressure increases, response times may increase gradually due to an increase in GC frequency. Balloons inflate first in the least active virtual machines where the increased GC is less likely to be disruptive.
The effect on performance varies proportionally with how much medium to long-lived data is created by the workload. If your application just responds to Web requests and avoids storing long-lived stated in the heap, there should be little effect on performance from EM4J ballooning. The effect increases when you save long-lived state in the heap and the tenured generation grows, reducing the portion of the heap available for ballooning and forcing more frequent GC.
In contrast, the inability of the VMware Tools balloon to reclaim memory from Java has the potential to cause sudden, unpredictable, and significant drops in performance. EM4J helps the system behave gracefully and predictably when memory becomes scarce. It helps you to more easily determine the over-commit ratio that provides acceptable performance at peak loads.