On Mon, 31 Aug 2026 00:57:38 GMT, David Holmes <[email protected]> wrote:
> I've been following here and in the mailing list discussion and I am
> confused. The problem as stated is that large mysterious int[] appear in the
> heap dump. But we specifically added special types for filler objects so that
> they do not appear as int[]. So which filler objects are appearing as int[]
> and why?
Yeah, that is a good question. And the answer is a bit is confusing.
Filler arrays are still type arrays with `T_INT` elements from the runtime
perspective:
void Universe::genesis(TRAPS) {
...
// Initialization of the fillerArrayKlass must come before regular
// int-TypeArrayKlass so that the int-Array mirror points to the
// int-TypeArrayKlass.
_fillerArrayKlass = TypeArrayKlass::create_klass(T_INT,
"[Ljdk/internal/vm/FillerElement;", CHECK);
Only the paths that ask the actual klass can discern the filler from "regular"
`int[]`:
inline bool CollectedHeap::is_filler_object(oop obj) {
Klass* k = obj->klass_without_asserts();
return k == Universe::fillerArrayKlass() || k ==
vmClasses::FillerObject_klass();
}
...and heap dump isn't:
} else if (o->is_typeArray()) {
// create a HPROF_GC_PRIM_ARRAY_DUMP record for each type array
DumperSupport::dump_prim_array(writer(), typeArrayOop(o));
}
I am guessing this is so that GC would not accidentally oop-scan the "filler"
obj-array? 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:
> - logs/heap dumps now contain instances of these objects - which seems fine
> as previously they have just been reported as part of j.l.Object/int-arrays
> statistics. The VM spec also does not guarantee whether a particular kind of
> object should/should not show there anyway.
Anyhow, it looks more straight-forward to avoid exposing fillers in heap dumps
to begin with.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/32542#issuecomment-5474249336
