Yeah, also not happy about a larger heap dump but I’ve also seen so many issues with filtering that I agree, the benefit outweighs the ugliness. In my opinion, it is up to the tooling to understand what it is looking at and make the appropriate adjustment. I’ve done this for years with GC logs. Might I suggest the new type for a filler that dumping the filler its self dumps information about the filler so that tools might interpret that? Yeah I know, an ugly idea….
Kind regards, Kirk > On Sep 3, 2026, at 4:57 PM, Aleksey Shipilev <[email protected]> wrote: > > On Wed, 26 Aug 2026 13:31:57 GMT, Oli Gillespie <[email protected]> > wrote: > >> Please review this simple change to remove filler arrays (and objects) from >> heap dumps. In the hprof format, they are not distinguishable from `int[]`, >> which can be confusing (where are these huge `int[]`s coming from in my >> application?), and they bloat the heap dump time and size. >> >> (Note: I sent a request for comments [on the serviceability-dev mailing >> list](https://mail.openjdk.org/archives/list/[email protected]/thread/USL6YYR2UW76Z4VFESN225ZASLL2DHYQ/) >> but got no response, so made a PR) >> >> Using Eclipse MAT, before: >> >> with-filler.hprof - 6.2GB >> >> Class Name | Objects | Shallow Heap >> ===================================== >> byte[] 39,938 4,997,553,360 >> int[] 45,839 1,140,524,000 >> >> >> After: >> >> without-filler.hprof - 5.0GB >> >> Class Name | Objects | Shallow Heap >> ===================================== >> byte[] 48,321 4,998,520,248 >> int[] 4,995 951,088 >> >> >> ([Test >> file](https://gist.github.com/olivergillespie/1661499afb9e1c708de30cf0bdfca30e)) >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Yeah. So it reinforces my argument: we are already stretching the definition > of typeArray internally to accommodate fillers. Exposing fillers in hprof is > trying to stretch the hprof format to shoehorn it there. It looks fairly > ugly, and I still do not believe the benefit outweighs this ugliness. The > heap dump size increase looks fairly bad: real services that run with larger > heaps plan for heap dumps related to heap size. With dumping `oop[]`, we are > now asking for twice the heap size in worst case? I think we _have to_ choose > the smaller array size to get heap dumps under control, even if tools > misinterpret it later. > > If we are exploring more crazy ideas, then maybe emit fillers at `float[]` -- > surely _those_ are not ubiquitous, especially at filler populations. (Bonus > points for renaming fillers to floaters, no-no, wait, no.) > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/32542#issuecomment-5527603872
