-Xloa / -Xnoloa
This option enables or prevents the allocation of a large object area (LOA) during garbage collection (GC).
Syntax
| Setting | Effect | Default |
|---|---|---|
-Xloa |
Enable LOA | yes (see Default behavior) |
-Xnoloa |
Disable LOA |
Default behavior
By default, allocations are made in the small object area (SOA). If there is no room in the SOA, and an object is larger than 64KB, the object is allocated in the LOA.
If the LOA is not used, it is shrunk to zero after a few collections. You can disable it explicitly by specifying the -Xnoloa option.
Explanation
The LOA is an area of the tenure area of the heap set used solely to satisfy allocations for large objects. The LOA is used when the allocation request cannot be satisfied in the main area (the SOA of the tenure heap.
As objects are allocated and freed, the heap can become fragmented in such a way that allocation can be met only by time-consuming compactions. This problem is more pronounced if an application allocates large objects. In an attempt to alleviate this problem, the LOA is allocated. A large object in this context is considered to be any object 64 KB or greater in size. Allocations for new TLH objects are not considered to be large objects.
This option is not supported with the balanced GC policy (-Xgcpolicy:balanced) or metronome GC policy (-Xgcpolicy:metronome), which do not use an LOA. Any LOA options passed on the command line are ignored. These policies address the issues that are solved by an LOA by reorganizing object layout with the VM to reduce heap fragmentation and compaction requirements.