On Tue, 1 Sep 2026 11:33:02 GMT, Oli Gillespie <[email protected]> wrote:
> Let's say we have a filler array of int[200] for 800 bytes of data. Do we
> represent that as FillerElement[100] for uncompressed oops and
> FillerElement[200] for compressed oops? Or always 200 and let the hprof
> consumer figure it out?
Better keep the length-fidelity, like other obj-arrays, IMO. Compressedoops can
already result into this kind of size-mismatch, afaics.
Small draft:
} else if (o->is_typeArray()) {
if (o->klass() == Universe::fillerArrayKlass()) {
// Present filler arrays with their friendly klass name instead of as
// int[]: dump them as object arrays with null elements.
int length = typeArrayOop(o)->length();
u4 size = checked_cast<u4>(1 + 2 * 4 + (2 + (size_t)length) *
sizeof(address));
writer()->start_sub_record(HPROF_GC_OBJ_ARRAY_DUMP, size);
writer()->write_objectID(o);
writer()->write_u4(STACK_TRACE_ID);
writer()->write_u4(length);
writer()->write_classID(o->klass()); // using the friendly klass
for (int i = 0; i < length; i++) {
writer()->write_objectID(oop(nullptr));
}
writer()->end_sub_record();
} else {
// ... same
}
}
> We can decide to show or not show some parts of it, especially fake ones.
Deviating too much from the actual-heap can probably cause confusing. Skipping
certain kinds of objs or not seems a decision that should be made downstream,
instead of in JVM. My 2c.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/32542#issuecomment-5505551717
