问题
When I am printing the details of garbage collection using GarbageCollectorMXBean the output shows me the following information:-
Name: PS ScavengeCollection
count: 72
Collection time: 3041
Memory Pools: PS Eden Space PS Survivor Space
Name: PS MarkSweepCollection
count: 5
Collection time: 4922
Memory Pools: PS Eden Space PS Survivor Space PS Old Gen
Now quite rightly the ScavengeCollection and MarkSweep collection covers 4 of the 5 available memory pool excluding
Code Cache (Non Heap Memory).
I want to know why the Garbage Collection never ran for
Code Cache Memory Pool managed by CodeCacheManager Memory Pool.
Does it imply that GC never garbage collect objects from CodeCacheManager Memory Pool??
Is there any significance of the same?
回答1:
Read the documentation for the MemoryMXBean. Specifically the part about Non-Heap Memory:
The Java virtual machine manages memory other than the heap (referred as non-heap memory). The Java virtual machine has a method area that is shared among all threads. The method area belongs to non-heap memory. It stores per-class structures such as a runtime constant pool, field and method data, and the code for methods and constructors. It is created at the Java virtual machine start-up.
The method area is logically part of the heap but a Java virtual machine implementation may choose not to either garbage collect or compact it. Similar to the heap, the method area may be of a fixed size or may be expanded and shrunk. The memory for the method area does not need to be contiguous.
In addition to the method area, a Java virtual machine implementation may require memory for internal processing or optimization which also belongs to non-heap memory. For example, the JIT compiler requires memory for storing the native machine code translated from the Java virtual machine code for high performance.
What falls into Non-Heap Memory you ask?
Permanent Generation: The pool containing all the reflective data of the virtual machine itself, such as class and method objects. With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas.
Code Cache: The HotSpot Java VM also includes a code cache, containing memory that is used for compilation and storage of native code.
回答2:
The code cache is a non-heap space that is garbage collected but not by the normal GC threads. Instead it is collected by the JIT's helper threads and so it won't show up in the same way other memory pools show up. Unfortunately the Code Cache MXBean doesn't support notifications and so you'll either have to poll or come up with another way to monitor memory usage.
All said, total memory usage may not help as code blobs in the code cache cannot be moved meaning the code cache cannot be compacted. Thus you may have lots of memory but if it's fragmented you still could suffer an allocation failure which.. if cannot be correct by the JIT threads aggressively cleaning the cache will cause the JIT to shutdown. It will not be restarted during the lifetime of the JVM.
来源：https://stackoverflow.com/questions/10493348/garbage-collection-not-running-for-code-cache-memory-pool