The System Dictionary hashtable bucket array size is fixed at 1009. This value is too small for large programs with many names, too large for small programs and just about right for medium sized ones. The default should remain at 1009, but it should be possible to override it on the command line.Finally, this has happened in JDK 8 and you can set hashtable bucket array size to be larger if you have more classes loaded in your applications by using:[2]
- -XX:+UnlockExperimentalVMOptions -XX:PredictedLoadedClassCount=<#>
In this article, we will look into sizing system dictionary in more details.
Performance of System Dictionary
In 1.4.2, there were some performance enhancements. One of them is making system dictionary reads lock-free.[3] From this enhancement, you probably can guess that tuning system dictionary could be important to the JVM's performance.
The current number of buckets in hash table for system dictionary is set to be 1009 by default, which is relatively small for an application which has 49987 classes loaded as shown below:
Loaded Bytes Unloaded Bytes Time 49987 110488.8 2453 7743.8 105.24
From the experience, we know:[5]
In a good hash table, each bucket has zero or one entries, and sometimes two or three, but rarely more than that.Assuming the average ideal length of buckets is three, the hashtable bucket array size then should be:
Ideal hashtable bucket array size = 49987 / 3 = 16662
System Dictionary Tuning
Seeing 49987classes loaded in our application at end of its run, we decided to set:
-XX:PredictedLoadedClassCount=16661 (a prime)
Note that PredictedLoadedClassCount is an experimental flag. So, you also need to set:
-XX:+UnlockExperimentalVMOptionsbefore it in the command line.
When the JVM allocates memory, the largest chunk is the java heap. The system dictionary is in C heap and it is the loaded class cache. The goal of setting PredictedLoadedClassCount flag is to increase the size of the system dictionary in order to make lookups of loaded classes faster. Before every class being loaded, it requires a checking to see if the class is already loaded. Larger system dictionary will improve JVM performance during this class loading and resolution phase.
Note that the total number of entries in the hashtable does not change— that is based on the number of loaded classes. What sizing of system dictionary do is to increase the spread of the entries so that the average length of the buckets under a single hash result could be reduced. This would reduce the time it takes to find a given entry.
How to Find Number of Loaded Classes?
There are multiple ways to find out number of loaded classes in an application. For example, you can use -Xverbose:class to determine what classes are loaded. Another way to find out is what we have done in this article by setting -XX:+PerfDataSaveToFile and then use "jstat -class" command to decipher the class statistics offline:
$<snipped>/jdk-hs/bin/jstat -class file:////slot/myserver/appmgr/APPTOP/instance/domains/slcaf977.us.oracle.com/CRMDomain/hsperfdata_9872
Loaded Bytes Unloaded Bytes Time 49987 110488.8 2453 7743.8 105.24
Acknowledgement
Some writings here are based on the feedback from Mikael Gerdin and Karen Kinnear. However, the author would assume the full responsibility for the content himself.
References
- Make system dictionary hashtable bucket array size configurable (JDK-7114376)
- Tuning the JVM (at 43:02 mark)
- Java 2 Platform, Standard Edition (J2SE Platform), version 1.4.2 Performance White Paper
- The Class Loader Subsystem
- Hash table (Wikipedia)
- VM Class Loading
- Actually, the HotSpot VM maintains three main hash tables to track class loading
- SystemDictionary
- PlaceholderTable
- LoaderConstraintTable
- Garbage-First Garbage Collector Tuning
No comments:
Post a Comment