Problem:
When migrating from Zulu JVM to Zing, the startup performance went from ~7 minutes to ~45 minutes. This was a simple Zing JVM running TomCat in a Docker instance (12GB RAM, 6 Cores, 8GB heap).
Startup performance can be debugged by capturing the GC log and using the GC Log Analyzer tool ($JAVA_HOME/etc/GCLogAnalyzer2.jar) to analyze it.
However, in this case there was not very much activity in the GC log and nothing to explain the long startup time. Compiler activity was relatively quiet.
Cause:
Customer had previously used the following 3 "excludec2" directives with Zulu:
-XX:CompileCommand=excludec2,org.springframework.core.ResolvableType::as
-XX:CompileCommand=excludec2,org.springframework.beans.factory.support.AbstractBeanFactory::getObjectForBeanInstance
-XX:CompileCommand=excludec2,sun.reflect.GeneratedMethodAccessor*
but was using the Falcon Compiler with Zing. Falcon currently ignores "excludec2".
The following combination was determined to be the cause:
- since "excludec2" was ignored, Falcon compiler had a huge memory requirement
- -Xms2GB. Zulu uses the -Xms parameter to start with a smaller heap, where Zing ignores it and immediately grows heap to (maximum) -Xmx, thereby causing a lot of disk swapping to occur (which didn't occur in Zulu)
- Customer's heap was too large to work efficiently with a 12GB docker instance. A larger instance or smaller heap should help improve performance
Solution:
Replace the previouse "excludec2" directives with "excludefalcon". For example:
-XX:CompileCommand=excludefalcon,org.springframework.core.ResolvableType::as
-XX:CompileCommand=excludefalcon,org.springframework.beans.factory.support.AbstractBeanFactory::getObjectForBeanInstance
-XX:CompileCommand=excludefalcon,sun.reflect.GeneratedMethodAccessor*
This will reduce the load on the Falcon compiler to match what was observed in Zulu.
Add Comment
Comments
Article is closed for comments.