G1GC is mainly designed for one thing, keeping your application responsive by:

trying to avoid that garbage collection of the "old gen" (the tenured objects that the application has hold on to for some time, like from a user session, cache, or some kind of memory leak) must be done in a single classic FullGC where your application is frozen while the entire heap has to be cleaned (which depending on the number of objects may take a long time, like several seconds. Read all about it here, one quote from it:

The goal is to reclaim as much heap space as possible (starting with those regions that contain the most reclaimable space) while attempting to not exceed the pause time goal

The 40% you set for the: InitiatingHeapOccupancyPercent relate to the (entire) heap occupancy and denote when to start a concurrent GC cycle (this should be visible in the logs, if not see: this related question ). GCs that trigger a concurrent GC cycle based on the occupancy of the entire heap and not just one of the generations (so not just Old Gen), including G1, use this option. A value of 0 denotes 'do constant GC cycles'. The default value is 45. (Adapted from: Oracle® Communications WebRTC Session Controller System Administrator's Guide )

So it is possible that:

1. The GC cycle is initiated at 40% heap occupancy but before it is finished you reach a much higher level (like 90%), which may be entirely fine as long as your application is working
2. You have some kind of memory leak (but that is hard to tell from the graph without knowing the application and how long it is running or see how it plays out after a longer time)
3. There may be some other problems but it is impossible to tell without having the garbage collection logs to analyse, but you may want to refer to: Monica Beckwith's article on G1GC e.g. the part on Evacuation Failure

If you really want your application to use less memory (maybe at the price of some loss in performance/throughput) you could lower the MaxHeapSize (but you should use either one of: MaxRAMFraction or MaxHeapSize (XmX), not both).

Or depending on your application and performance requirements consider going for an entirely different JVM/Garbage Collector like:

• IBM/Eclipse OpenJ9 (see: https://developer.ibm.com/articles/garbage-collection-tradeoffs-and-tuning-with-openj9/ which is touted as having a very low memory overhead)
• or any other GC mentioned in this research on Java memory elasticity discussing Shenandoah, ZGC, C4 and many others

JDK-6976060 suggests that the need for a marking cycle is calculated at the end of a young GC. Depending on whether it uses the occupancy stats before or after the young GC this may or may not mean that eden space is always considered as 0% occupied for the purpose of IHOP calculation. With a 45% eden size that would mean 70% occupancy could never be reached, the maximum possible occupancy would be 55% and at that point the heap would be completely full and it would be too late for a mixed collection.

But I am doubtful whether this is truly the case because in the face of dynamic young generation sizing this would make the documentation misleading and IHOP tuning far more difficult. It should be fairly easy to verify this with an artificial test-case and manually sized generations.

If that's not the issue then GC pause (GCLocker Initiated GC) (young) might point to bug 8140597, which is fixed in jdk9b94.

Update: The description in Bug 8151176 indeed suggests that for the purpose of the IHO-percentage calculation it calculates oldgen occupancy/overall heap size. Which means young generation occupancy is completely ignored, which in turn means if young gen fraction > IHOP then it can never initiate a concurrent cycle.

The reason is that static IHOP starts if old gen occupancy exceeds a fixed percentage of the current heap capacity. If either the user or ergonomics decide that the old gen can not be larger than that fraction of the heap capacity that triggers concurrent mark, marking will never start.

So currently available solutions are

• constrain the young gen fraction < IHOP
• decrease IHOP to take the minimum possible old gen fraction into account
• let the JVM adjust the IHOP dynamically

Update2: The latest comment on that bug indicates that this has been fixed for some time, so this answer should be considered as historic.