Garbage Collection not running for Code Cache Memory Pool

Question

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?

Midlands

Answer 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.

Selfgovernment

Thanks for the link BUT I have already gone through it.Infact before actually using MXBean I went through the same link for understanding NotificationEmitter. Now coming back your post does not really answer my question.I want to know why GC never ran for Code Cache.If it is JVM dependent then there may certain scenarios under which Code Cache will be available for GC.Also if my code cache contains many objects which are eligible for GC but GC never ran doesn't in indicate a potential loopHole? – Midlands

If you want to test this empirically, you need to run JConsole - view the code cache, fill it up to the max (which is going to be hard), and see what happens. The code cache is used for method that are compiled by the JVM. You can't program against that directly. – Selfgovernment

Answer 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.

Stinker