We could of course emit object instances like `FillerArrayPlaceholder {
sizeBytes=100,000 }`, retaining all information without bloat. But that's
wading into strange territory and seems to go against the format.
________________________________
From: Kirk Pepperdine <[email protected]>
Sent: 03 September 2026 16:22
To: Aleksey Shipilev <[email protected]>
Cc: [email protected] <[email protected]>;
[email protected] <[email protected]>;
[email protected] <[email protected]>
Subject: [EXTERNAL] [External] : Re: RFR: 8372389: Omit filler arrays from heap
dump
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
Yeah, also not happy about a larger heap dump but I’ve also seen so many issues
with filtering that I agree, the benefit outweighs the ugliness. In my opinion,
it is up to the tooling to understand what it is looking at and make the
appropriate adjustment. I’ve done this for years with GC logs. Might I suggest
the new type for a filler that dumping the filler its self dumps information
about the filler so that tools might interpret that? Yeah I know, an ugly idea….
Kind regards,
Kirk
> On Sep 3, 2026, at 4:57 PM, Aleksey Shipilev <[email protected]> wrote:
>
> 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
Amazon Development Centre (London) Ltd. Registered in England and Wales with
registration number 04543232 with its registered office at 1 Principal Place,
Worship Street, London EC2A 2FA, United Kingdom.
