By default, ActiveSpaces® Transactions doesn't modify the JVM heap (-Xms<size> and -Xmx<size>) or stack (-Xss<size>) memory options. If during testing, the JVM is found to run short of, or out of memory, these options can be modified either setting them as arguments to the deployment tool.

Both JConsole and VisualVM can be used for looking at heap memory utilization.

By default, ActiveSpaces® Transactions doesn't modify any of the JVM garbage collection parameters.

For production systems deploying using the Oracle JVM, we recommend that you enable garbage collection logging using the following deployment options:

This will be provide a relatively low overhead logging that can be used to look for memory issues and using the timestamps may be correlated to other application logging (e.g. request/response latency).

Another useful set of Oracle JVM option controls GC log file rotation. See (Java HotSpot VM Options).

Garbage collection tuning is a complex subject with dependencies upon the application, the target load, and the desired balance of application throughput, latency, and footprint. Because there is no best one-size-fits-all answer, most JVMs offer a variety of options for modifying the behavior of the garbage collector. An Internet search will show a large selection of writings on the subject. One book with good coverage on the implementation and tuning of garbage collection in Oracle JVMs is Java Performance by Charlie Hunt and Binu John.

As mentioned above, it is hard to make garbage collection tuning suggestions for a generic application environment such as ActiveSpaces® Transactions . However, here is a comment from our field engineering organization with respect to tuning rules engine applications builtin on top of the \ActiveSpaces® Transactions runtime:

We've found that a good garbage collection algorithm for a BE-X application is concurrent mark sweep ... although this is application dependent, it's probably a good start:

Another good collector, available in JDK 7 and later, is G1. Liveview testing showed it to perform well throughput optimization on systems that don't a have huge amount (more than 10 or 20 gigabytes) of heap to manage.

When deploying using the Oracle JVM we recommend setting the following JVM deploy option which will cause a JVM heap dump to be logged upon an out of memory error within the JVM:

-XX:+HeapDumpOnOutOfMemoryError

Typically, an ActiveSpaces® Transactions deployment will consist of a single JVM per node. However, there may be cases where multiple JVMs per node are required (e.g. Exceeding a per-process limit on the number of file descriptors).

ActiveSpaces® Transactions supports multiple JVMs deployed within a single node. These JVMs may all access the same Managed objects.

Multiple JVMs are deployed by using the detach option to the deployment tool.