Hi Guys, We Alibaba have experienced the same problem as Man introduced. Some applications got frequent concurrent mark cycles and high cpu usage and even some to-space exhausted failures because of large amount of humongous object allocation even with G1HeapRegionSize=32m. But those applications worked fine with ParNew/CMS. We are working on some enhancements for better reclamation of humongous objects. Our first intention is to reduce the frequent concurrent cycles and possible to-space exhausted so the heap utility or arraylets are not taken into consideration yet. Our solution is more like a ParNew/CMS flow and will treat a humongous object as young or old. 1. Humongous object allocation in mutator will be considered into eden size and won't directly trigger concurrent mark cycle. That will avoid the possible to-space exhausted while concurrent mark is working and humongous allocations are "eating" the free regions. 2. Enhance the reclamation of short-live humongous object by covering object array that current eager reclaim only supports primitive type for now. This part looks same to JDK-8048180 and JDK-8073288 Thomas mentioned. The evacuation flow will iterate the humongous object array as a regular object if the humongous object is "young" which can be distinguished by the "age" field in markoop. The patch is being tested. We will share it once it proves to work fine with our applications. I don't know if any similar approach has been already tried and any advices? Thanks, Liang