Uncollected garbage

[Kirill Ilyukhin]

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