Uncollected garbage

Kirill Ilyukhin kilyukhin at gmail.com
Tue Jan 18 04:32:47 UTC 2022


Roman, Aleksey,

Could you please reply?

Thank you,
Kirill

On Mon, 27 Dec 2021 at 10:57, Kirill Ilyukhin <kilyukhin at gmail.com> wrote:

> Roman, Aleksey,
>
> I have to accept the "filler object" explanation.
> I could not reproduce the issue on a test server. These int arrays keep
> accumulating but the memory is reclaimed when heap usage reaches 70-80%.
>
> Now the question is why did it take that long to reclaim the memory?
> Before a restart the JVM was running about 2 hours 20 minutes with heap
> usage more than 80%, including ~30 minutes with usage ~90%. Please see the
> GCeasy report in my previous mail.
>
> Thank you,
> Kirill
>
> On Mon, 20 Dec 2021 at 23:29, Kirill Ilyukhin <kilyukhin at gmail.com> wrote:
>
>> Roman, Aleksey,
>>
>> Here is what I got at the moment.
>>
>> Looks like these arrays are really eventually reclaimed, but after more
>> than an hour of high GC activity and nearly 100% CPU usage. Seems a bit
>> late.
>> Please see GCeasy report at
>> https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjEvMTIvMjAvLS1nYy4yMDIxLTEyLTExXzA5LTAzLTI5LmxvZy5nei0tMTMtOC0yMg==&channel=WEB
>>
>> int arrays size corresponds to PNG images size. The biggest are:
>> 678x840 - 569,520 elements = 2,278,104 bytes
>> 452x560 - 253,120 elements = 1,012,480 byte
>>
>> Please see full GC log at https://kilyukhin.github.io/gc.awt.image.log.gz
>>
>> I will run with -verbose:gc and get back to you later.
>>
>> Thank you,
>> Kirill
>>
>> On Mon, 20 Dec 2021 at 20:39, Roman Kennke <rkennke at redhat.com> wrote:
>>
>>> > The heap usage is nearly 100% , with these int[] objects occupying
>>> 87%. The
>>> > JVM process consumes ~100% of CPU, most of which is GC trying to free
>>> up
>>> > some memory. Does this fit into "filler objects" explanation?
>>>
>>> Hmm, no, not really.
>>>
>>> AFAIK, those image objects carry their int[] for image data, and they
>>> are accessed by native code, too. Native access to arrays pins the
>>> arrays and their containing region. It seems plausible that frequent
>>> native access to image data prevents those regions from being collected,
>>> at least as long as the region contains one live/reachable image data
>>> array. Eventually, those *should* be reclaimed.
>>>
>>> Can you post heap configuration that is printed by -verbose:gc when
>>> application starts, and also typical size of the int arrays?
>>>
>>> Thanks,
>>> Roman
>>>
>>>


More information about the shenandoah-dev mailing list