For unrelated change, I looked at `ptype /ox Klass` on recent mainline, and noticed considerable holes:
```
$ gdb shipilev-jdk/build/linux-aarch64-server-release/images/jdk/bin/java
...
(gdb) run
...
(gdb) ptype /ox Klass
...
/* 0x0098 | 0x0008 */ class ClassLoaderData *_class_loader_data;
/* 0x00a0 | 0x0008 */ uintx _bitmap;
/* 0x00a8 | 0x0001 */ uint8_t _hash_slot;
/* XXX 3-byte hole */
/* 0x00ac | 0x0004 */ int _vtable_len;
/* 0x00b0 | 0x0004 */ class AccessFlags {
private:
/* 0x00b0 | 0x0004 */ jint _flags;
/* total size (bytes): 4 */
} _access_flags;
/* XXX 4-byte hole */
/* 0x00b8 | 0x0008 */ traceid _trace_id;
private:
/* 0x00c0 | 0x0002 */ s2 _shared_class_path_index;
/* 0x00c2 | 0x0002 */ u2 _shared_class_flags;
...
```
I believe this is caused by introduction of `uint8_t _hash_slot` withJDK-8180450. We can just move that field somewhere later to avoid `_access_flags` and `_trace_id` alignment gaps.
```
$ gdb shipilev-jdk/build/linux-aarch64-server-release/images/jdk/bin/java
...
(gdb) run
...
(gdb) ptype /ox Klass
...
/* 0x0098 | 0x0008 */ class ClassLoaderData *_class_loader_data;
/* 0x00a0 | 0x0008 */ uintx _bitmap;
/* 0x00a8 | 0x0001 */ uint8_t _hash_slot;
/* XXX 3-byte hole */
/* 0x00ac | 0x0004 */ int _vtable_len;
/* 0x00b0 | 0x0004 */ class AccessFlags {
private:
/* 0x00b0 | 0x0004 */ jint _flags;
/* total size (bytes): 4 */
} _access_flags;
/* XXX 4-byte hole */
/* 0x00b8 | 0x0008 */ traceid _trace_id;
private:
/* 0x00c0 | 0x0002 */ s2 _shared_class_path_index;
/* 0x00c2 | 0x0002 */ u2 _shared_class_flags;
...
```
I believe this is caused by introduction of `uint8_t _hash_slot` with
- relates to
-
JDK-8180450 secondary_super_cache does not scale well
- Resolved