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
