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). The klass of the filler array already has an appropriate name: _fillerArrayKlass = TypeArrayKlass::create_klass(T_INT, "[Ljdk/internal/vm/FillerElement;", CHECK); for (int i = T_BOOLEAN; i < T_LONG+1; i++) { _typeArrayKlasses[i] = TypeArrayKlass::create_klass((BasicType)i, CHECK); } it's just that the heap dumper sees "this is some kind of array klass (TypeArrayKlass)", and then ignores the name of the TypeArrayKlass with it friendly name, assuming that the name ("[something") is always derived from the element type. jstat -histo instead uses the actual names to collect data. Note that the current behavior is the same as before the filler arrays were introduced, i.e. with older JDKs you would also get tons of int-arrays in the heap - because that's what GC did, filling the heap with int-arrays. Note that there is no real jdk.internal.FillerElement, so synthesizing a fake object array also has the problem of that class not actually existing (i.e. has no class id), but that might not be an insurmountable issue. 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 (and just make the values in the dump all-null?). Maybe worth exploring this path if you really want the distinction between those two. Another option is, if it is sometimes important to also see filler sizes, make suppression of filler objects opt-in. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32542#issuecomment-5492941910 PR Comment: https://git.openjdk.org/jdk/pull/32542#issuecomment-5492948963
