Class Merging

How Class Merging Works

Class merging is a representation-level optimisation, not a semantic change to the program. The compiler or runtime tries to collapse two classes into one shared layout when their fields, methods, inheritance relationships, and access patterns are compatible enough that object access still behaves correctly. The benefit is lower metadata overhead, less duplication, and sometimes simpler execution paths.

The key constraint is structural equivalence. If two classes differ in field order, type shape, method dispatch expectations, object initialisation rules, or any runtime assumption that callers rely on, merging can break correctness. That makes the optimisation highly implementation-dependent: it is only safe when the language runtime can prove that the merged representation preserves observable behaviour.

Why It Exists in Compilers and Runtimes

Class merging is used to reduce memory footprint and to remove redundant class definitions that would otherwise consume space and create extra indirection. In managed runtimes, this can also improve cache locality and reduce the work needed to load or materialise class metadata. In ahead-of-time compilation, it may help shrink binaries or simplify generated code where multiple classes are effectively equivalent after optimisation.

This kind of optimisation is most valuable in systems that generate many structurally similar classes, such as code generated from templates, proxies, wrappers, or other tooling-heavy build pipelines. The runtime or compiler is effectively trading a more compact internal model for stricter compatibility checks.

Correctness Boundaries and Failure Modes

Class merging only works when the runtime can preserve object identity, field access, type checks, and dispatch semantics. Even if two classes look similar on paper, subtle differences such as reflection behaviour, serialisation metadata, access modifiers, or subtype relationships can make a merge unsafe. The optimisation therefore needs strong guards around what counts as compatible.

When those guards are too loose, the result is usually not a performance issue but a correctness bug. Mis-merged classes can produce wrong field reads, invalid casts, broken method resolution, or unexpected behaviour in code that depends on precise type boundaries. For that reason, class merging is often treated as an internal compiler transformation that must be validated carefully rather than exposed as a user-facing feature.

Where It Fits in the Optimisation Pipeline

Class merging is one technique within a broader set of code-size and performance optimisations. It is usually considered alongside inlining, dead-code elimination, class deduplication, and layout compression. The important distinction is that class merging changes how types are represented internally, while many other optimisations change how code is executed without collapsing type structures.

Because it affects the object model, class merging tends to be applied conservatively and late in the optimisation pipeline, after the compiler or runtime has enough information to prove equivalence. That is why it is common in systems that have whole-program visibility or runtime profiling, but less common in environments where type boundaries must remain fully dynamic.

Risk and Threat Considerations

Class merging is not itself a security feature, but it can become security-relevant when incorrect compatibility assumptions expose type confusion, broken isolation between classes, or unsafe handling of reflective metadata. If a runtime merges representations too aggressively, security-sensitive code may observe the wrong class shape or trust an object identity boundary that no longer exists.

Failure mechanism: Incorrect equivalence checks allow two semantically distinct classes to share one representation, which can corrupt type safety, dispatch behaviour, or metadata handling.

Impact: The consequence is usually correctness failure first, but in security-sensitive runtimes it can also widen the blast radius of a memory-safety bug, weaken isolation assumptions, or create unexpected access to methods or state.

Practitioner Guidance

What to watch for: Treat class merging as a correctness-sensitive optimisation that needs regression coverage around reflection, serialisation, inheritance, and any code path that depends on exact type identity. The most reliable implementations are conservative about what they merge and explicit about the invariants they require.

Practitioner takeaway: If class merging is enabled in a toolchain or runtime, validate it against the language features your codebase actually uses, not just against microbenchmarks or code-size gains.

Related resources from NHI Mgmt Group

• What breaks when machine identities are not governed like first-class identities?
• What breaks when enterprise agents are not treated as first-class identities?
• Why do storage-class permissions matter so much in Kubernetes security?
• What do teams get wrong about account merging in multi-IdP applications?