Hi, You're talking about 8392345 which omits filler objects from -live dumps? I figured that was fairly clear-cut, since these are not reachable objects (it's unfortunate that the docs conflate performing a full gc with removing unreachable objects, but several parts of the doc are clear that only reachable objects are expected in a live dump). Presumably just using -all isn't enough for you, since you want to see how it looks after compaction? You can still get close by triggering a full gc and then taking a -all dump.
'to address a bug in MAT' - it's not just MAT, it's a fundamental information loss that the filler arrays are not directly identifiable as such. Other tools like Java Object Layout (JOL) have the same problem (worse in some ways. Tools like that understandably don't consider reachability, so filler arrays in 'live' dumps can be even more confusing than in MAT, where at least they're marked unreachable and researching 'unreachable int arrays' might give you some clues). For the wider problem: 1. Can we make filler arrays identifiable in heap dumps? We've discussed proposals, I don't love any of them but some might be workable. I'm not currently planning on taking that further unless a clear consensus emerges. I may at least zero the arrays to reduce confusion (users can otherwise be tempted to try to figure out the source of the int arrays from their mysterious contents), avoid data leakage and improve compressibility. I maintain that filler objects do not fit in the current definition of a heap dump, but I accept they have value, and if we can limit their negative impact (primarily confusion) then I don't mind the conceptual impurity. 2. Should we extend the format (explicitly, with new types, or implicitly with synthetic instances like 'G1RegionInfo'), or indeed create a new format, to better serve observability needs? More VM internal details would certainly be useful in some cases. Actual object layout, region boundaries, object age, TLABs etc., would all be valuable, and we could directly encode the waste that filler indirectly points to. Using current heap dumps to understand heap layout is even worse with Valhalla and flat representations, perhaps it's a good time to improve things. I would start from the use-cases (HeapDumpOnOutOfMemoryError - I want to know why I OOMed, I want to understand some particular occupancy metric, I want to reduce footprint, ...). ________________________________ From: Kirk Pepperdine Sent: Wednesday, September 16, 2026 19:10 To: Oli Gillespie Cc: [email protected]; [email protected]; [email protected] Subject: [EXTERNAL] [UNVERIFIED SENDER] [External] : Re: RFR: 8372389: Omit filler arrays from heap dump Hi Oli, I’m sorry to say that once again, I’m uncomfortable with filtering data out of a profile. I’m not sure of what the requirement that is driving this work but again, this feels like it’s being done here to address a bug in MAT. I would be happier if the filler was something easier to recognize such as what was proposed for the -all case. In my case, removing it impacts my ability to analyze heap fragmentation. I’m curious to know why the earlier proposal for the -all case wouldn’t also work for the -live case. Maybe there is an alternate means of representing the filler data that won’t break existing tooling. After all, (and likely unfortunately) the hprof format isn’t a spec. I’ve only been able to slot time in to have a deeper look at this next week. Kind regards, Kirk Pepperdine > On Sep 16, 2026, at 6:40 PM, Oli Gillespie <[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). > > https://github.com/openjdk/jdk/pull/32860 omits filler for 'live' dumps, > fixing a clear bug (thanks Thomas for pointing it out), please take a look. > > We still need to decide if/how to represent filler for non-live dumps. We can > probably agree on dumping zeros instead of the actual heap contents at least, > if we do keep them. > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/32542#issuecomment-5701037273 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.
