gc causes
- gcCause.cpp
switch (cause) {
case _java_lang_system_gc: return "System.gc()";
case _full_gc_alot: return "FullGCAlot";
case _scavenge_alot: return "ScavengeAlot";
case _allocation_profiler: return "Allocation Profiler";
case _jvmti_force_gc: return "JvmtiEnv ForceGarbageCollection";
case _gc_locker: return "GCLocker Initiated GC";
case _heap_inspection: return "Heap Inspection Initiated GC";
case _heap_dump: return "Heap Dump Initiated GC";
case _wb_young_gc: return "WhiteBox Initiated Young GC";
case _update_allocation_context_stats_inc:
case _update_allocation_context_stats_full:
return "Update Allocation Context Stats";
case _no_gc: return "No GC";
case _allocation_failure: return "Allocation Failure";
case _tenured_generation_full: return "Tenured Generation Full";
case _metadata_GC_threshold: return "Metadata GC Threshold";
case _cms_generation_full: return "CMS Generation Full";
case _cms_initial_mark: return "CMS Initial Mark";
case _cms_final_remark: return "CMS Final Remark";
case _cms_concurrent_mark: return "CMS Concurrent Mark";
case _old_generation_expanded_on_last_scavenge:
return "Old Generation Expanded On Last Scavenge";
case _old_generation_too_full_to_scavenge:
return "Old Generation Too Full To Scavenge";
case _adaptive_size_policy: return "Ergonomics";
case _g1_inc_collection_pause: return "G1 Evacuation Pause";
case _g1_humongous_allocation: return "G1 Humongous Allocation";
case _last_ditch_collection: return "Last ditch collection";
case _last_gc_cause: return "ILLEGAL VALUE - last gc cause - ILLEGAL VALUE";
default: return "unknown GCCause";}
- common occurred and explanation
- System.gc
- Something called System.gc().
- If you are seeing this once an hour it is likely related to the RMI GC interval
- sun.rmi.dgc.client.gcInterval
- sun.rmi.dgc.server.gcInterval
- 两个参数默认都是1hour
-
关于rmi的distributed garbage collection-gcInterval
- RMI uses a distributed garbage collection (DGC) algorithm that depends on regular garbage collection (GC) activity to determine if remote objects are candidates for collection. It helps with automatic memory management when remote objects are stored in memory
- To ensure that the remote objects are collected in a timely fashion, RMI takes the step of triggering a System.gc() on a regular interval. However, in most cases regular GC activity is sufficient for effective DGC.
- Disabling Explicit Garbage Collections
- -XX:+DisableExplicitGC(关闭它会影响堆外内存回收)
- Do both server and client arguments need to be added?
- The two sun.rmi arguments reflect whether your JVM is running in server or client mode. Depending on the version of your SDK, either mode can be set as the default. It is best to set both options so the argument will be picked up by the JVM
- Allocation_Profiler
- Prior to java 8 you would see this if running with the -Xaprof setting. It would be triggered just before the jvm exits. The -Xaprof option was removed in java 8.
- Aprof
- Aprof is a Java memory allocation profiler with very low performance impact on the profiled application that can be used (and is used) on highly-loaded server-side applications in production environment. It acts as an agent which transforms class bytecode by inserting counter increments wherever memory allocation is done and tracks a precise size of allocated objects in bytes. It also keeps limited information about allocation context to aid in finding the memory allocation bottlenecks. links
- aprof-bug
- JvmtiEnv_ForceGarbageCollection
- Something called the JVM tool interface function ForceGarbageCollection. Look at the -agentlib param to java to see what agents are configured.(instrument agent?)
- ForceGarbageCollection
- http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html
- jvmtiError ForceGarbageCollection(jvmtiEnv* env)
- Force the VM to perform a garbage collection. The garbage collection is as complete as possible. This function does not cause finalizers to be run. This function does not return until the garbage collection is finished.
- Although garbage collection is as complete as possible there is no guarantee that all ObjectFree events will have been sent by the time that this function returns. In particular, an object may be prevented from being freed because it is awaiting finalization.
- GCLocker_Initiated_GC
- The GC locker prevents GC from occurring when JNI code is in a critical region. If GC is needed while a thread is in a critical region, then it will allow them to complete, i.e. call the corresponding release function. Other threads will not be permitted to enter a critical region. Once all threads are out of critical regions a GC event will be triggered.
- jni funcations
- GetStringCritical, ReleaseStringCritical
- GetPrimitiveArrayCritical, ReleasePrimitiveArrayCritical
- c/c++代码里引用jstring, jarray,通过指针引用而不是把数据copy from java heap to native heap为了性能
- 防止操作时jstring,jarray的指针随gc改变,需要gclocker来pin住gc happen
- Heap_Inspection_Initiated_GC
- GC was initiated by an inspection operation on the heap. For example you can trigger this with jmap: jmap -histo:live <pid>
- Heap_Dump_Initiated_GC
- GC was initiated before dumping the heap. For example you can trigger this with jmap: jmap -dump:live,format=b,file=heap.out <pid>
Another common example would be clicking the Heap Dump button on the Monitor tab in jvisualvm.
- GC was initiated before dumping the heap. For example you can trigger this with jmap: jmap -dump:live,format=b,file=heap.out <pid>
- No_GC
- Used for CMS to indicate concurrent phases.
- Allocation_Failure
- Usually this means that there is an allocation request that is bigger than the available space in young generation and will typically be associated with a minor GC.
- For G1 this will likely be a major GC and it is more common to see G1_Evacuation_Pause for routine minor collections.
- On linux the jvm will trigger a GC if the kernel indicates there isn't much memory left via mem_notify.
- CMS_Initial_Mark
- Initial mark phase of CMS, for more details see Phases of CMS. Unfortunately it doesn't appear to be reported via the mbeans and we just get No_GC.
- CMS_Final_Remark
- Remark phase of CMS, for more details see Phases of CMS. Unfortunately it doesn't appear to be reported via the mbeans and we just get No_GC.
- CMS_Concurrent_Mark
- Concurrent mark phase of CMS, for more details see Phases of CMS. Unfortunately it doesn't appear to be reported via the mbeans and we just get No_GC.
- Ergonomics
- This indicates you are using the adaptive size policy, -XX:+UseAdaptiveSizePolicy and is on by default for recent versions, with the parallel collector (-XX:+UseParallelGC). For more details see The Why of GC Ergonomics.
- Last_ditch_collection
- For perm gen (java 7 or earlier) and metaspace (java 8+) a last ditch collection will be triggered if an allocation fails and the memory pool cannot be expanded.
- System.gc
- References