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). In order of my preference: 1. Omit fillers in heap dumps 2. Include them but label them sensibly and zero them (representation as null elements should cover this automatically). A bit more complex. Loses the size/perf benefits, and adds 4-byte/8-byte confusion (I think). 3. Omit them by default, include with a flag 4. Include them by default, omit with a flag I think a flag suits almost no-one. If they're included by default, then everyone gets the confusion problem that we're trying to solve. By the time you know enough to set the flag, it's too late. If they're omitted by default, then the flag is for people who want to understand filler waste. But that can be observed in other ways (humongous region tails are derivable from the heap dump anyway, and TLAB waste has logs/metrics), so you only need it if maybe you're getting a heap dump from an environment you don't control, so you probably wouldn't have set the flag already. Instead of adding heap dump flags to expose a little bit of data about filler, why not just cover any gaps in logs/metrics. So I won't work on 3/4. If people like, I can see how painful 2 looks. But so far I've only heard one opinion against 1. > I do not think considering 8 or 4 bytes references is an issue, I think the > length of that filler array must be a multiple of 8 anyway, so it's just a > matter of correctly passing the array length I don't follow. Let's say we have a filler array of `int[200]` for 800 bytes of data. Do we represent that as `FillerElement[100]` for uncompressed oops and `FillerElement[200]` for compressed oops? Or always `200` and let the hprof consumer figure it out? ------------- PR Comment: https://git.openjdk.org/jdk/pull/32542#issuecomment-5493282447
