RFR: 8319548: Unexpected internal name for Filler array klass causes error in VisualVM

[Thomas Schatzl]

On Wed, 20 Dec 2023 02:46:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm still struggling with what we are doing with this filler array stuff. IIUC the underlying type is actually `int[]` but we pretend it is `FillerElement[]`. 

The reason for having dedicated filler array klasses is detecting internally in the GC that we are currently looking at a dead object. That the VM can distinguish dead objects from live objects is required for some functionality (like heap dumping only live classes, but also verification) without undue performance (basically need to redo marking every time this is needed) or memory usage hit (1.5% of maximum Java heap size) when invoking some APIs.

E.g. any reference from a live object to a dead object will immediately assert.

There is also improved debugability due to that - i.e. if you see a reference to any such klass in a hs_err file, it is 99% an error with a reference where the barrier has been forgotten.

The reason for having a custom array type and not having a klass referencing `int` elements is because Hotspot does not support that.

> Won't exposing this fake type just lead to further problems if tools try to inspect one of these arrays as-if it were an `Object[]` ??

We do not expose these arrays to regular APIs (e.g. we filter them out when iterating available klasses), and they are never referenced by other live objects by definition. So it is impossible for a Java application to get a reference to such objects or these klasses.

The only way they are exposed is in a heap dump also containing dead objects (and related functionality like the `jcmd` class histogram). Somebody at some time thought that this would be an interesting feature so we need to support it.

Previously one would get the same dead objects in that output just intermingled with other `int[]` arrays. Imo this discrimination is preferable and much more useful for heap analysis.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17155#issuecomment-1864069245