Uncollected garbage

[Kirill Ilyukhin]

Francisco,

Thank you for the note.
Would it help if I make a raw GC log file accessible from the internet?

Thank you,
Kirill

On Tue, 18 Jan 2022 at 14:30, Francisco De Melo Junior <fdemeloj at redhat.com>
wrote:

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