Java Garbage Collection

I re-read "Java Performance" by Charlie Hunt and here is some general information about garbage collection - mainly for my own reference:

The Java heap size is the size of the young generation and the old generation spaces (does not include the permanent generation) (p.111)

The app memory is the heap size + the perm generation + the threads stack size (p.277)

There are three aspects to garbage collection (p.262)

• Throughput: How much time is spend in garbage collection vs. how much time is spend on executing application code
• Latency/Responsiveness: How much pause time in executing application code does GC introduce, i.e. how is the response time affected by GC
• Memory: The amount of memory used

GC Monitoring

Switch on GC monitoring using: -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:<filename> -> Analyze using GCHisto (p.121)

To shows how long the applicaton runs and how long GC takes add: -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime (p.120)


The occupancy of the young generation after a minor GC is the survivor space occupancy (p.111) 

The live data size is the amount of memory of long-lived objects in old and perm generation. It is the size of the heap after a full GC - calculate an average of multiple full GCs (p.113, 268, 274)


The parallel garbage collector is using adative heap sizing, i.e. the HotStop VM initially uses explicit young generation sizing settings (-Xmn, -XX:NewSize, ...) and the automatically adjusts young generation spaces sizes from those settings. This can be disables using the -XX:-UseAdaptiveSizePolicy flag. (p.105 & http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc-ergonomics.html)

If you wanted to know what GC ergonomics was thinking, try adding -XX:+PrintAdaptiveSizePolicy or -XX:AdaptiveSizePolicyOutputInterval=1. The later will print out information every i-th GC about what the GC ergonomics to trying to do. (https://blogs.oracle.com/jonthecollector/entry/the_unspoken_the_why_of)


Heap size starting points (p.276)

• Set -Xms & -Xmx to 3 to 4 times the live data size of the old generation
• Set -XX:PermSize and -XX:MaxPermSize to 1.2 to 1.5 times the live data size of the perm generation
• The young generation should be 1 to 1.5 times the live data size of the old generation
• The old generation should be 2 to 3 times the live data size of the old generation

If young GC is takes too long reduce young generation size - if it occures too frequently increase it (p.280)

A parallel (throughput) garbage collector overhead of near 1% is considered well tuned. With >3% overhead tuning may improve the applications performance. It should be less than 5%. The larger the heap the better the opporunity for lower gc overhead - but this will also increase the max. stop-the-world time. p. 122/314

If worst case full GC time is unacceptable switch to a concurrent GC (Concurrent Mark Sweep or G1) (p.287)

Samaxes Minify Maven Plugin & Eclipse - Deployment to Tomcat

I started using the Samaxes Minify Maven Plugin to minify my JavaScript and CSS files.The usage is pretty easy and I ended up with the following config in my POM

<plugin>
 <groupId>com.samaxes.maven</groupId>
 <artifactId>minify-maven-plugin</artifactId>
 <version>1.7.2</version>
 <executions>
  <execution>
   <id>default-minify</id>
   <phase>generate-resources</phase>
   <configuration>
    <charset>UTF-8</charset>
    <cssSourceDir>css</cssSourceDir>
    <cssSourceFiles>
     <cssSourceFile>x.css</cssSourceFile>
     <cssSourceFile>y.css</cssSourceFile>
     <cssSourceFile>z.css</cssSourceFile>
    </cssSourceFiles>
    <cssFinalFile>style.css</cssFinalFile>
    <jsSourceDir>js</jsSourceDir>
    <jsSourceFiles>
     <jsSourceFile>x.js</jsSourceFile>
     <jsSourceFile>y.js</jsSourceFile>
     <jsSourceFile>z.js</jsSourceFile>
    </jsSourceFiles>
    <jsFinalFile>script.js</jsFinalFile>
    <jsEngine>CLOSURE</jsEngine>
    <webappTargetDir>${basedir}/src/main/webapp</webappTargetDir>
   </configuration>
   <goals>
    <goal>minify</goal>
   </goals>
  </execution>
 </executions>
</plugin>

This worked fine when I ran 'mvn clean install' from my command line.

But I am also using Eclipse (with the whole ecosystem of  m2e / WTP / m2e-wtp) and Tomcat from within Eclipse. And I wanted to be able to publish the generated resources "script-min.js" and "style-min.css" to Tomcat using Eclipse.

Here is what I did in the end:

Did you notice the line in the plugin configuration.

<webappTargetDir>${basedir}/src/main/webapp</webappTargetDir>

By default the Minify Maven Plugin generates the resource into the 'target' folder. By setting this parameter I let the plugin generate the resources into the same folder as the source js and css files.

Now one simply has to run 'mvn generate-resources' either from the command line or from within Eclipse and then do a "Refresh" (F5) on the project and afterwards call 'Publish' on the Tomcat from within Eclipse. If Tomcat is already running it will even auto-publish the change.

This is it and this is what I do.

Note 1:

As an alternative to running 'mvn generate-resources' one can also call "Clean" on the project and let m2e rebuild it. There is just one additional thing if one want to go with this alternative: By default m2e does not execute the "Minify Maven Plugin" so you have to tell it to do so in your pom.xml:

<pluginManagement>
 <plugins>
  <plugin>
   <groupId>org.eclipse.m2e</groupId>
   <artifactId>lifecycle-mapping</artifactId>
   <version>1.0.0</version>
   <configuration>
    <lifecycleMappingMetadata>
     <pluginExecutions>
      <pluginExecution>
       <!-- We need to add this so that m2e (maven2eclipse) will execute the minify-maven-plugin's goal 'minify' when it builds the eclipse project -->
       <pluginExecutionFilter>
        <groupId>com.samaxes.maven</groupId>
        <artifactId>minify-maven-plugin</artifactId>
        <versionRange>[1.0.0,)</versionRange>
        <goals>
         <goal>minify</goal>
        </goals>
       </pluginExecutionFilter>
       <action>
        <execute />
       </action>
      </pluginExecution>
     </pluginExecutions>
    </lifecycleMappingMetadata>
   </configuration>
  </plugin>
 </plugins>
</pluginManagement>

That's it.

Note 2: Within the 'm2e lifecyce mapping' configuration I also tried to set

<execute>
 <runOnIncremental≶true</runOnIncremental>
</execute>

which would generate "script-min.js" and "style-min.css" each time one made a change to any of the source js or css files. This worked nicely when I manually called 'Publish' but I encountered a problem when Tomat was running and trying to auto-publish the changes:

When I changed one of the JS/CSS files Eclipse would get into an endless loop of automatically republishing and building the project.

As I do not very often change the JS/CSS files in this project I decided it was best to go with the manual steps of running 'mvn generate-resources' (from Eclipse), refreshing by hitting F5, and then publishing.

Oracle HotSpot JVM Command Line Flags

Find information about all the Oracle HotSpot JVM Command Line Flags:

• http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
• http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

One can use -XX:+PrintCommandLineFlags to see the default command line flags. For example

C:\>java -XX:+PrintCommandLineFlags -version

-XX:InitialHeapSize=263467392 -XX:MaxHeapSize=4215478272 -XX:+PrintCommandLineFlags 
-XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation 
-XX:+UseParallelGC
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)

tells us that Java 8 uses the Parallell Garbage Collector as a default (-XX:+UseParallelGC) garbage collector, that the default min heap size is 1/64 (263467392 bytes - about 250MB) of my machines RAM (16GB) and the default max heap size is 25% (4215478272 bytes - about 4 GB), of my machines RAM.

One can also find out the value of a specific command line flag using the tool jinfo. For example

C:\>jinfo -flag MaxHeapSize 3216

-XX:MaxHeapSize=4217372672

tells us again the value of the max heap size. 3216 is the process id of the Java process you are interested in. You can find out the process ids of locally running Java processes using the tool jps

C:\>jps

3216 Bootstrap
5872 Jps
2944 org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar