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). Given that: 1. Heap dump is a fairly generic re-interpretation of heap _contents_ -- no instance sizes, no exact field layouts, no real addresses, etc. -- only the tightly controlled stuff. 2. Filler objects are "fake" in the sense that nothing actually allocated them -- GC is merely reinterpreting the "free" memory as fake object to gain heap parsability -- and they do not consume the actual heap space. 3. Filler objects are not zeroed during their "creation" -- their contents are (potentially sensitive) garbage data from already GC-ed objects -- which both erodes our security posture at worst, and carries (incompressible) garbage in our already large dumps at best. 4. There is an apparent architectural disconnect between filler arrays being both typeArray-s and having non-typeArray synthetic klass, which would require more fiddling around VM code to expose them properly, if we decide to double-down on that path. ...I firmly believe filler objects need to be treated as internal implementation detail, and never leak through the generic interfaces like heapdump. It is IMO a historical accident that we report them. jmap is an internal tool, and I think it is pragmatic to draw the line in the sand there: internal tools are allowed peek into internal VM details in a controlled manner. Heap dumps must not dump them raw. The only bonus for fillers in heap dump I can see is following up on edge cases when fillers show there is an unoccupied space. Which _may_ be a signal for a heap fragmentation that GC cannot deal with, but it is IMO not readily distinguishable from the normal case when filler just sits on the top of not-yet-allocated heap region. Which we cannot easily distinguish due to (1), we have already lost quite a bit of internal layout data. So, on balance, I think exposing fillers in heap dump brings more problems than it solves. Chasing edge use cases just yields more busy work to deal with (3) and (4) without a significant gain. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32542#issuecomment-5493467107
