RFR: JDK-8211150: G1 Full GC not purging code root memory and hence causing memory leak
Poonam Parhar
poonam.bajaj at oracle.com
Tue Oct 2 13:41:26 UTC 2018
Hello Thomas,
Thanks for the review! I have moved purge_code_root_memory() after the
rebuild_strong_code_roots() call.
http://cr.openjdk.java.net/~poonam/8211150/webrev.01/
Thanks,
Poonam
On 10/1/18 1:33 PM, Thomas Schatzl wrote:
> Hi Poonam,
>
> On Mon, 2018-10-01 at 09:39 -0700, Poonam Parhar wrote:
>> Hello,
>>
>> Please review this simple code change that fixes a memory leak during
>> the G1 Full GC cycle.
>>
>> JDK-8211150: G1 Full GC not purging code root memory and hence
>> causing memory leak
>>
>> Webrev: http://cr.openjdk.java.net/~poonam/8211150/webrev/
>>
>> Problem and fix: During G1 Full collections, the code root memory is
>> not being deallocated, and that causes a leak for processes invoking
>> only Full GCs (e.g. using System.gc()). The above change fixes that
>> leak. Please see the attached images showing the memory allocations
>> of a process creating lots of Thread objects and invoking
>> System.gc(), before and after this fix. The allocations profile is
>> collected using jemalloc. Before-fix image clearly shows that the new
>> entries created in G1CodeRootSetTableEntry are not being deleted in
>> Full collections.
> while the change is correct, I would expect that placing the
> purge_code_root_memory() call after the rebuild_strong_code_roots()
> call, as otherwise to-be-purged objects created during that time would
> carry over to the next GC. I.e. needlessly keep them alive.
>
> Thanks,
> Thomas
>
>
More information about the hotspot-gc-dev
mailing list