large size of [Ljdk.internal.vm.FillerElement in jmap histo

[Aleksey Shipilev]

On 25.07.24 17:54, shanghe chen wrote:
> Hi in a web service with openjdk 21.0.3 using G1GC with heap size 26GB, we recently sometimes 
> observed a huge jump up of the oldgen like from 9GB to 20GB in about 3 minutes and then slowly 
> returned to 9GB (which is the normal size) in about 30 minutes, checking jmap histo we found:
> 
>   num     #instances         #bytes  class name (module)
> -------------------------------------------------------
>     1:       6328181    16406573984  [Ljdk.internal.vm.FillerElement; (java.base at 21.0.3)
>     2:      18920559     1233399640  [Ljava.lang.Object; (java.base at 21.0.3)
>     3:      18813814      848534768  [B (java.base at 21.0.3)
>     4:       5939383      771222984  [I (java.base at 21.0.3)
>     5:       3093810      654462640  [J (java.base at 21.0.3)
>     6:      15519103      496611296  java.util.HashMap$Node (java.base at 21.0.3)
>     7:      17985808      431659392  java.util.Date (java.base at 21.0.3)
>     8:      17415598      417974352  java.util.ArrayList (java.base at 21.0.3)
>     9:      16857329      404575896  java.lang.String (java.base at 21.0.3)
>    10:       9743073      389722920  java.math.BigDecimal (java.base at 21.0.3)
>    11:       4410896      281417160  [Ljava.util.HashMap$Node; (java.base at 21.0.3)
> 
> Any idea for why the class jdk.internal.vm.FillerElement has so large size? There seems to be less 
> document for this class. Thanks in advanced!

Those are filler arrays, they are not "real" reachable objects. See more here:
  https://shipilev.net/jvm/anatomy-quarks/5-tlabs-and-heap-parsability/

-Aleksey



Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597