Zing Startup Performance poor compared to Zulu

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.