A JVM service generates a large number of classes at run time and its start-up time is dominated by class loading. How does the bytecode verification phase factor into that cost, and what levers would you consider?

## Where the time actually goes Class loading is several distinct pieces of work: locating and reading bytes, parsing the class file into runtime structures, **verifying**, preparing, and building method tables — plus the cost of any loader logic on top. Verification is a meaningful share of it, and unlike reading bytes it does not benefit from the page cache on a second start. The modern verifier is a linear pass that checks each instruction against the frames declared in the `StackMapTable`, so cost is roughly proportional to bytecode length, with extra work at branch targets and exception handlers where frames must be checked and merged. A service that generates one small class per request shape, per proxy, per mapper, per serializer can create thousands of classes and pay this thousands of times. One asymmetry matters: HotSpot distinguishes classes loaded by the bootstrap loader — trusted, not verified by default — from everything else, which is verified. So JDK classes are cheap on this axis and your generated classes are not. ## The levers, from most to least leverage **1. Generate fewer classes.** This dominates everything else because each class costs parsing, verification, metadata, method tables, and permanent metaspace footprint. Concretely: cache generated classes by shape rather than per instance; collapse near-identical generated classes into one parameterized implementation; replace a generated adapter with a `MethodHandle` chain or a hidden class where the runtime supports it; or fall back to a reflective or data-driven implementation for cold paths and generate only for the hot ones. "Generate lazily, and only where it pays" is usually a bigger win than any flag. **2. Generate simpler bytecode.** Long methods with many branches and exception handlers cost more to verify and more to compile later. Emitting several small methods, or avoiding elaborate generated control flow, reduces both. **3. Archive the linked form.** Class-data sharing maps a prepared archive of classes into memory so that parsing and verification are not repeated on every JVM start. Application class-data sharing extends this beyond JDK classes to the application's own classes, and dynamic archiving captures classes actually used in a run. Recent JDKs go further with ahead-of-time caches that store classes already loaded and linked from a training run. The relevant judgment is operational: archives must be regenerated when the application's classes change, and they help repeated start-ups, not a single one. **4. Get the frames right, and budget their computation.** Generated bytecode must carry a correct `StackMapTable` or it is rejected with `VerifyError` at load. Generation libraries can compute frames for you, but frame computation costs generation time — a real trade when classes are produced on the request path. Emitting frames yourself during generation, when the shape is known, avoids paying for a general analysis. **5. Not a lever: turning verification off.** `-Xverify:none` and `-noverify` were deprecated in JDK 13 and are ignored from JDK 18 onward. Even where they still worked, they removed the invariant that makes running arbitrary bytecode safe, in exchange for a shrinking benefit. ## How to decide Measure before choosing. Class-loading events in a flight recording, the count of loaded classes over time, and metaspace growth tell you whether generation volume, verification, or something else entirely (loader locking, resource lookup, initialization work) dominates. The answer is often that class *count* is the problem — in which case the architectural fix, generating fewer and reusing more, is both the largest win and the one that also reduces metaspace, JIT compilation and footprint. Flags and archives are the follow-up, not the opening move.