Reducing memory for OxygenXML

[csalsa]

I am writing this as we received new workstations running Windows XP that unfortunately have a 2GB memory limit. Moving to Windows 7 or adding more memory are not options. So I tinkered with the JVM settings in the oxygen.vmoptions so see if I could reduce memory consumption. I was able to reduce memory usage significantly.

My investigation was with OxygenXML 12 but following the release of OxygenXML 13 found similar benefits with the modified settings. My testing was to start OxygenXML and load five XML files and validate them against a common schema.

To reduce the consumption of memory I first added the JVM options:
-XX:MaxHeapFreeRatio=40
-XX:MinHeapFreeRatio=20
These settings reduce the free heap memory. I did not experiment with settings such as 'NewRatio', 'NewSize', 'SurvivorRatio' as they are hard to test.

For the GC collector, I first tried:
-XX:+UseParallelGC
-XX:+UseConcMarkSweepGC
These settings worked better than the original setting of 'UseParallelGC'.

Then I tried the Incremental GC for which development has been stopped.
-Xincgc
Surprisingly this worked the best.


My final settings were:
-Xincgc
-XX:MaxHeapFreeRatio=40
-XX:MinHeapFreeRatio=20

Is there someone with JVM experience who could comment on my choice of settings?

[adrian]

Hello,

It's a good idea to adjust Min/MaxHeapFreeRatio if you want to minimize the memory footprint of the Java application. We have looked into these ourselves and 20/40 is probably a good combination for an economical JVM. You can use these with good results if you only edit small files in Oxygen(<10MB).

I believe the defaults of the JVM are:
-XX:MinHeapFreeRatio=40
-XX:MaxHeapFreeRatio=70
These allow the JVM to consume a lot more memory than necessary but they also make it ready for large memory allocations.

Regarding -Xincgc and the rest of the GC flags, I'd recommend avoiding them and sticking with the simple -XX:+UseParallelGC. We've tested it for some time now and it's very reliable. You can have some serious stability and also performance issues(hick-ups) with some of the GC flags.

Also, regarding -XX:+UseConcMarkSweepGC, note that it cannot be used together with -XX:+UseParallelGC. The command line JVM reports:

Conflicting collector combinations in option list; please refer to the release notes for the combinations allowed

I can't comment on -Xincgc, might be unstable if it's not maintained.


BTW, if you want to test combinations of these flags you should add them in the oxygen.bat(last line), run the .bat in the command prompt and keep an eye on the console. This way you'll spot any warnings the JVM reports.

You can find a list of JVM options here:
Java HotSpot VM Options
Note that some of these are somewhat unstable can can cause some trouble for the application.

Also there's an article on a blog that studies the various GC algorithms:
All About Java Garbage Collection : Types, Algorithms, Advantages and Disadvantages

Regards,
Adrian

[csalsa]

Thanks Adrian for your response.

I was careless. I pasted the wrong combination of switches. I should have put:
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
The combination I put in my first post conflicts as you pointed out.

What we produce are real-time web services with strict response times and thus small payloads. We have a suite of over 500 web services but only eight of these services have samples with more than 50kB with the largest service message being a response of 200kB. This is two orders of magnitude less than the 10MB you mentioned in your post.

I take heed of your warning of stability but so far our team of thirty service designers have not reported a problem with the settings I selected.

[csalsa]

Adrian,

I got the idea of using -Xincgc from:
Tuning Garbage Collection Outline

The posting is for tuning Java 1.4.2 which is three major releases old.

Incremental Low Pause Collector
- Sometimes called Train Collector
- Collects a portion of the tenured generation at each minor collection.
- Tries to minimize large pause of major collections
- Slower than the default collector when considering overall throughput
- Good for client apps (my observation)
- -Xincgc

The author observations were 'good fro client apps'.