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). Running jmap -histo on some application gives the following output: num #instances #bytes class name (module) ------------------------------------------------------- 1: 206379289 4953102936 java.util.LinkedList$Node (java.base@28-internal) 2: 1617588 4300111560 [Ljdk.internal.vm.FillerElement; (java.base@28-internal) 3: 206379539 3302072624 java.lang.Integer (java.base@28-internal) 4: 8424786 269593152 java.util.LinkedHashMap$Entry (java.base@28-internal) 5: 13290548 212648768 java.lang.Long (java.base@28-internal) 6: 8424788 202194912 java.util.LinkedList (java.base@28-internal) 7: 271 33598544 [Ljava.util.HashMap$Node; (java.base@28-internal) 8: 11508 461744 [B (java.base@28-internal) 9: 11413 273912 java.lang.String (java.base@28-internal) 10: 1830 241408 java.lang.Class (java.base@28-internal) 11: 1227 158024 [Ljava.lang.Object; (java.base@28-internal) 12: 3801 91224 java.util.HashMap$Node (java.base@28-internal) 13: 218 55280 [C (java.base@28-internal) 14: 1172 44688 [I (java.base@28-internal) Ie. the VM distinguishes between filler arrays ([Ljdk.internal.vm.FillerElement;) and random integer arrays [I. > I am guessing this is so that GC would not accidentally oop-scan the "filler" > obj-array? It is fine to scan the filler object array, but it is better to just ignore it in some cases (vs. an int array which gc might want to handle in some cases). It's also better for error diagnosis to see that some live object actually references a filler obj vs. an int[] array. Because the latter might be correct, the former never is. >So [JDK-8284435](https://bugs.openjdk.org/browse/JDK-8284435) did not actually >created the fully-typed FillerElement[] as filler array. Which is also weird, >because that same change apparently expected these types to show up in heap >dump https://bugs.openjdk.org/browse/JDK-8319548 fixed that, see above. Heap dumping simply has not been made aware of distinguishing [..FillerElement; vs. int arrays. Oversight/bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32542#issuecomment-5476073358
