NOTE
JVM Object Allocation
How HotSpot commonly allocates objects, including TLABs, young-generation allocation, large objects, promotion, and why exact rules depend on the collector.
This is a historical learning note and may contain outdated or incomplete understanding.
1. Fast Allocation Path
In HotSpot, many ordinary objects are allocated from a thread-local allocation buffer (TLAB). A thread can advance a local allocation pointer without contending on one global heap lock.
If a TLAB cannot satisfy the allocation, the JVM uses a slower shared/collector-specific path.
2. Young-Generation Allocation
Generational collectors usually allocate most short-lived objects into young-generation space because most objects die young. Surviving objects may move between survivor/old regions according to collector policy.
Do not treat one fixed “age threshold” or one exact Eden/Survivor ratio as a JVM-wide law; these are collector and configuration details.
3. Large Objects
Large-object handling varies substantially by collector. Some collectors may allocate or treat humongous objects specially instead of following the ordinary small-object path.
4. Allocation Failure
An allocation request can trigger GC or expansion attempts. OutOfMemoryError occurs only after the JVM cannot satisfy the requested allocation under its configured/runtime constraints.
5. Practical Takeaway
Reason first about allocation rate, object lifetime, live-set size, and collector behavior. Use GC logs/JFR/profilers to verify actual behavior instead of relying on historical fixed thresholds.