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). I've implemented the 'emit as FillerElement[]` approach in https://github.com/openjdk/jdk/pull/32687, for comparison. It's simple enough, the quirks are: 1. Object array elements are 8 bytes in hprof, so dumps are larger with lots of filler. 2. As discussed, footprint estimate is messed up. Tools like MAT will assume oop size, but to keep the length correct we're breaking that assumption for uncompressed oops. We can have _either_ correct length or (mostly) correct footprint. It solves most of the confusion and the data leak. It doesn't solve performance overhead. It regresses dump size. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32542#issuecomment-5527164086
