I’d almost agree with you. However, a heap dump is a profile that contains a single sample. t’s format has no specification. We’re trying to correct it by substituting “bad information” for better information (since we don’t have perfect information. I’ll return to my previous argument that it is up to the tooling to understand what it is working with. In this case a FillerArrayPlaceholder the tooling either understands and treats the information accordingly or it doesn’t and it appears as an object with no allocation site and no root, pretty much the same as the int[]. Tools get a “fix” for “free” and aware tools are able to offer more.
Kind regards, Kirk Pepperdine > On Sep 3, 2026, at 5:46 PM, Gillespie, Oli <[email protected]> wrote: > > We could of course emit object instances like `FillerArrayPlaceholder { > sizeBytes=100,000 }`, retaining all information without bloat. But that's > wading into strange territory and seems to go against the format. > From: Kirk Pepperdine <[email protected] <mailto:[email protected]>> > Sent: 03 September 2026 16:22 > To: Aleksey Shipilev <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> > Subject: [EXTERNAL] [External] : Re: RFR: 8372389: Omit filler arrays from > heap dump > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you can confirm the sender and know the > content is safe. > > > > 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 > > > > > 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.
