Bumping this - does anyone have any objection to excluding filler objects from heap dumps?
Oli ________________________________ From: Gillespie, Oli Sent: 18 August 2026 15:29 To: [email protected] <[email protected]> Subject: Omit GC filler objects from heap dump Proposal: exclude filler objects from heap dumps. They confuse more than they help. I've had a few cases where filler arrays in heap dumps confused me for quite a while. It's okay in things like GC.class_histogram as they have the identifying name of "[Ljdk.internal.vm.FillerArray", but in other tools like Eclipse MAT they still show up as plain int arrays. Normally unreachable objects would not be looked at much, I get that, but here are the cases I heard about recently. 1 - HeapDumpOnOutOfMemoryError produced a heap dump, which only had around 20% space filled with reachable objects, the rest unreachable. I figured the unreachable stuff must be relevant to the OOM. Actually, the 'OutOfMemoryError: java heap space' was triggered by GCLocker retry count exceeded, the JVM was not out of heap space at all. 2 - a service had an issue with periodic allocation spikes causing G1 full GC. They enabled HeapDumpBeforeFullGC to understand the garbage that was triggering the full gc. Many large int arrays seemed suspicious, but in the end they were mostly fillers. I propose the simple option of excluding filler objects from heap dumps, but if there's a way to instead make these identifiable in MAT and other tools, that would also be fine. I wonder if Valhalla might provide any options here to represent the filler elements not as primitives but as values? Feedback appreciated! Oli (Filler object background - https://tschatzl.github.io/2022/09/26/jdk-vm-internal-fillerarray.html) Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.
