Deep analysis on simultaneous use of UseAdaptiveSizePolicy and CMS garbage collection

O. conditions that may cause problems in practical applications: 1. JMX obtains memory information. 2. jvm startup parameters use-XX: + UseAdaptiveSizePolicy and-XX: + useconcmarksweepgc3at the same time. This issue has been fixed by using all versions of sun jdk (1.6.30 and later versions 1.7 and, note: UseAdaptiveSizePolicy and MaxGCPauseMillis are applicable to Parallel GC (General server jvm mode, such as 64-bit windows and linux operating systems. The GC mode is used by default, for more versions, refer to the official documentation or use java-version to check whether the server mode is used. We do not recommend that you use it in CMS. To analyze an issue with HBase (parallel GC, CMS, and these parameters are put together in the jvm configuration of the official version provided by CDH, which leads to this problem because we didn't doubt this at first, for example: 1. Exception: 1) program exception 14:01:21, 159 FATAL org. apache. hadoop. hbase. regionserver. HRegionServer: ABORTING region server SERVER_SERVER: Unhandled exception: committed = 10729504768 shocould be <max = 10379526144 java. lang. illegalArgumentException: committed = 10729504768 shocould be <max = 10379526144 at java. lang. man Agement. memoryUsage. <init> (MemoryUsage. java: 145) at sun. management. memoryImpl. getMemoryUsage0 (Native Method) at sun. management. memoryImpl. getHeapMemoryUsage (MemoryImpl. java: 61) at org. apache. hadoop. hbase. regionserver. HRegionServer. buildServerLoad (HRegionServer. java: 932) at org. apache. hadoop. hbase. regionserver. HRegionServer. tryRegionServerReport (HRegionServer. java: 906) at org. apache. hadoop. hbase. re Gionserver. HRegionServer. run (HRegionServer. java: 770) at java. lang. thread. run (Thread. java: 662) 14:01:21, 160 FATAL org. apache. hadoop. hbase. regionserver. HRegionServer: RegionServer abort: loaded coprocessors are: [] 2) jmap-heap result: (this is true for all nodes in the cluster. Therefore, we guess jvm parameter configuration) Debugger attached successfully. server compiler detected. JVM version is 20.5-b03 using parallel threads in the new generation. using threa D-local object allocation. concurrent Mark-Sweep GC Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 10737418240 (10240.0 MB) NewSize = 2147483648 (2048.0 MB) MaxNewSize = 2147483648 (2048.0 MB) oldSize = 5439488 (5.1875 MB) NewRatio = 2 bytes vorratio = 4 PermSize = 21757952 (20.75 MB) MaxPermSize = 134217728 (128.0 MB) Heap Usage: unknown generation type: capacity = 0 (0.0 MB) Used = 0 (0.0 MB) free = 0 (0.0 MB) NaN % usedunknown generation type: capacity = 0 (0.0 MB) used = 0 (0.0 MB) free = 0 (0.0 MB) NaN % usedPerm Generation: capacity = 60878848 (58.05859375 MB) used = 37927152 (36.17015075683594 MB) free = 22951696 (21.888442993164062 MB) 62.29939173619054% used II. Result: in HBase, regionserver sets the status abortRequest, so HRegionServer. the run thread exits and other threads are running normally (jstack comparison shows ). In the abortRequest status, regionserver does not provide any data request services, so it cannot be used. 3. Cause 1) program exception: Check that the jvm bug is detected. Check that the version is 1.6 _ u30 or above, including 1.7. (You cannot log on to the official bugs.sun.com to confirm the problem ), JDK 1.6 or earlier versions have not been confirmed (no recurrence problem has been found after version _ u25 is used ). Cause brief analysis: (http://blog.csdn.net/axman/article/details/8667351) with the cms algorithm, if the UseAdaptiveSizePolicy parameter is enabled, the eden, from, and to size will be recalculated each time after minor gc, the calculation process is based on statistics of the gc process. After calculation, the eden + from + to does not exceed Xmx, at the same time, the from and to are generally not equal (the from and to are equal during initialization ). The main problem is that after calculation, if the eden becomes larger, the max_eden_size in the ContiguousSpacePool is not updated or the value at the beginning. This causes the jvm to call java through call_special. lang. management. the MemoryUsage constructor generates an exception because eden committed is larger than max_size of eden, leading to the return of java. lang. management. the MemoryUsage object fails, leading to display exceptions. Sun's jdk has not modified this bug so far. JVM Implementation Analysis: management. in cpp Code, the commit is accumulated when the heap memory size is calculated, but total_max is not accumulated when max_size is not defined (invalid, obtained from MemoryPool, as a result, commited is larger than max. The repaired code can be found at: Repair. Comparison: originally only processing: if (! Has_undefined_max_size) {total_max + = u. max_size ();} Method to Solve the Problem: Add code to handle cases where init and max are not defined. if (has_undefined_init_size) {total_init = (size_t)-1;} if (has_undefined_max_size) {total_max = (size_t)-1;} 2) Why jmap cannot be obtained: (UseAdaptiveSizePolicy + CMS will appear at the same time) (source code in this situation: sun/jvm/hotspot/memory/GenerationFactory. java): try {return (Generation) ctor. instantiateWrapperFor (addr);} catch (WrongTypeException e) {r Eturn new Generation (addr) {public String name () {return "unknown generation type ";...... 4. Solution: You can set-XX:-UseAdaptiveSizePolicy to workaround first. JDK version: After a sun jdk problem occurs, only JDK 8 is fixed. Openjdk is fixed by hs25.