Questions: Generics and Template Specialization

Question 1

A Rust program calls a generic sort function with 15 different concrete types. A Java program calls a generic sort function with the same 15 types. How do the compiled outputs differ?

• A. Both produce 15 specialized copies — Rust and Java both use monomorphization
• B. Rust produces 15 specialized copies; Java produces one shared version using type erasure
• C. Java produces 15 specialized copies; Rust produces one shared version via dictionary passing
• D. Both produce a single shared version — modern compilers always prefer smaller binaries

Answer: (B)

Rust uses monomorphization: the compiler generates a distinct, fully specialized function for each concrete type, so calling sort with 15 types produces 15 copies of the function in the binary, each optimized for its specific type. Java uses type erasure: the generic sort method compiles to a single bytecode implementation operating on Object references, with type casts inserted at boundaries. The Rust binary will be larger but faster (no boxing, no virtual dispatch); the Java binary will be smaller but pays the cost of indirection and boxing for primitive types.

Question 2

What is the core performance advantage of monomorphization over type erasure?

• A. Monomorphization allows faster compilation because types are resolved earlier
• B. Monomorphization produces type-specific code that the optimizer can inline, vectorize, and constant-fold without indirection
• C. Monomorphization eliminates the need for garbage collection, reducing runtime overhead
• D. Monomorphization shares code between instantiations, reducing instruction cache pressure

Answer: (B)

When a generic function is monomorphized for a specific type, the resulting code is identical to what you would have written by hand for that type. The optimizer has full knowledge of the concrete types involved and can eliminate virtual dispatch, inline function calls, vectorize loops over known-size data, and constant-fold type-specific computations. Type erasure sacrifices all of this: every operation goes through object references, primitives must be boxed into heap objects, and the optimizer cannot specialize based on type. The tradeoff is that monomorphization can inflate binary size when a generic is used with many types.

Question 3

Type erasure is typically slower than monomorphization because it discards most type information, leaving the runtime unable to perform any type-specific optimizations.

• T. True
• F. False

Answer: False

Type erasure discards generic type *parameters* at runtime, but compilers using erasure still perform type-checking at compile time and insert explicit type casts. The performance cost of erasure comes from indirection (operating on object references rather than direct values) and boxing (wrapping primitives in heap objects), not from total loss of optimization opportunity. JIT compilers (like the JVM's HotSpot) can still perform runtime optimizations such as method inlining based on observed types. The claim that 'all type information is lost' conflates the erasure of generic parameters with the loss of all type knowledge.

Question 4

In a language that uses type erasure for generics, a List<Integer> and a List<String> share the same compiled bytecode at runtime.

• T. True
• F. False

Answer: True

This is the defining characteristic of type erasure. In Java, `List<Integer>` and `List<String>` are identical at the bytecode level — both are just `List` operating on `Object` references. The generic type parameter exists only in the source code for compile-time type checking; by the time the code runs on the JVM, the type parameter has been erased. This is why you cannot, for example, write `new T()` in a Java generic method — the runtime doesn't know what T is.

Question 5

Explain the core tradeoff between monomorphization and type erasure in terms of runtime performance and binary size.

Model answer: Monomorphization generates a separate, fully specialized copy of the generic code for each concrete type used. This enables zero-cost abstraction — the compiler can optimize each copy as if it were hand-written for that type — but multiplies code size with every new type instantiation, potentially bloating the binary and pressuring instruction caches. Type erasure produces a single shared implementation operating on a uniform representation (typically object references), keeping binary size small regardless of how many types are used, but at the cost of indirection, boxing of primitives, and loss of type-specific optimization opportunities. The choice encodes a tradeoff between 'fast at runtime' and 'small in memory.'

Neither approach is universally better — the right choice depends on the language's goals and typical use cases. Systems languages (Rust, C++) favor monomorphization because performance is paramount and generics are often used with a small, fixed set of types. Application languages (Java, C#) favor erasure or hybrid approaches because developer productivity, binary size, and startup time matter more than peak throughput. Modern languages like Swift and C# explore intermediate strategies (specialization for critical types, sharing for others) to capture benefits of both.