Uncollected garbage

[Francisco De Melo Junior]

Fyi here. GCEasy (Ram's tool) might be misleading on Shenandoah since it
does report exactly the degenerate state as full gcs.
Use  https://github.com/openjdk/shenandoah-visualizer and see the actual gc
logs for more acurate information

-Francisco
On Sun, Dec 26, 2021 at 8:58 PM 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
> >>
> >>
>
>