Structural diversity & JIT
Limit the value of reusable shortcuts while respecting your application’s runtime budget.
Different bytes are not the entire objective#
A seed can change constants and names while leaving an analyst’s structural shortcut intact. The representation portfolio compares candidates across structural fingerprints, algebraic families and boundary characteristics. The distinction is deliberate: parameter variation and a change in the reconstruction problem are not equivalent forms of diversity.
Account for simplification#
A complicated expression in bytecode may simplify after optimization. The engine includes a model of selected HotSpot C2 canonicalization behavior and audits candidates for structural collapse. Observational minimization also removes perturbations that do not influence demanded output bits. Complexity that has no observable role is a weak basis for choosing a representation.
These are model-based selection signals, not measurements of every JVM or proof of resistance to every optimizer. Final runtime measurements still belong to the target application and JVM configuration.
Separate physical and runtime budgets#
Class-file size and runtime cost are different constraints. Selection can consider method bytes, constant-pool pressure, modeled JIT inlining and node budgets, live scalar state and allocations on hot paths. Region classification distinguishes hot loop kernels, warm domain logic and cold high-value paths, rather than assuming the same representation is appropriate everywhere.
Review what the release actually contains#
A stronger path can lose value if an easier equivalent path remains beside it. Release review therefore includes alternative-branch exposure and metadata leakage, not just the transformed body. The source project includes targeted inventory and archive-sanitization checks. Keep developer diagnostics and reconstruction aids outside the distributed artifact.