Developers often say allocating a small object on the JVM is cheaper than calling malloc in C. Mechanically, what does the JVM do on allocation that makes that plausible, and what does it pay for it later?

## Two different allocation problems A C-style allocator must satisfy requests from a heap that has been carved up by an arbitrary history of allocations and frees. It keeps free lists (usually per size class), searches one for a block that fits, may split a larger block, and on free may coalesce neighbours. It also has to be thread-safe, which in practice means per-thread caches plus locks on shared arenas. The work per call is small but variable, and fragmentation makes it worse over time. The JVM has arranged to avoid that problem for the common case. Its young space is collected by a copying (evacuating) collector: at each young collection the live objects are copied to survivor space or promoted, and the collected area is then wholly free. So there are never holes to track — free memory is one contiguous stretch. ## The fast path With contiguous free space, allocation reduces to arithmetic on a single pointer: the object goes at the current free pointer, and the pointer moves forward by the object's size. That is called bump-the-pointer allocation. To avoid making that pointer a contention hot spot, each thread bumps its own private slice of the young space, so the sequence needs no atomic instruction. The JIT compiler inlines the whole thing into the caller, so a `new` for a small class with a statically known size becomes roughly: load pointer, add constant, bounds check, store pointer, store mark word, store class pointer, done. A nuance often missed: object size must be known to do this. For a class it is fixed at class-load time; for an array it is computed from the length, which is why array allocation includes a length check and a size multiplication. ## What the JVM pays Three bills come due. **Zeroing.** The Java language guarantees fields start at 0, false, or null, so the memory must be cleared. Whether done in bulk when a buffer is handed out or per object, the cost is linear in bytes allocated. High allocation rates are partly a memory-bandwidth problem for this reason. **Collection frequency.** Bytes allocated per second divided by the size of the young space gives roughly how many young collections happen per second. Allocation does not cost time now; it schedules a pause later. **Survivor cost.** A copying collector's work is proportional to what survives, not to what was allocated. Objects that die before the next young collection cost essentially nothing to reclaim — they are simply not copied. Objects that survive are copied, possibly repeatedly, and eventually promoted, which is the expensive path. ## Why the comparison is still not a blank cheque Malloc does not stop your program later; the JVM's deferred cost shows up as pauses and as CPU spent in collector threads. And a manual allocator does not have to zero memory. The honest statement is: the JVM's allocation *operation* is cheaper and scales better across threads, and reclamation of short-lived data is nearly free, but total memory management cost is paid across allocation, zeroing, and collection, and is dominated by how much data survives. ## Practical consequence This is why the standard advice is not do not allocate but do not allocate objects that survive unnecessarily and do not allocate at a rate that saturates memory bandwidth. Small, short-lived, thread-confined objects are exactly the case the machinery is optimized for.