Deployment Manual / Version 2512.1
Table Of ContentsWhen the CAE or Headless Server processes high-resolution images, G1GC may allocate
Humongous Objects — objects larger than half the G1 region size — directly in the old
generation. Frequent Humongous allocations can cause back-to-back concurrent GC cycles and
old-generation heap fragmentation, eventually leading to an OutOfMemoryError.
To understand the scale of the problem, consider a typical large source image: a 4000×2000 px PNG at 8-bit colour depth decompresses to approximately 23 MB (RGB) or 30 MB (RGBA) of raw pixel data. During a transformation the pipeline holds source, working, and output buffers concurrently, so peak allocation for a single image operation can reach 50–90 MB.
The standard mitigation is to increase the G1 region size via -XX:G1HeapRegionSize. An
object is only considered Humongous when it exceeds half the region size, so a larger region
raises the threshold. Valid values are 1m, 2m, 4m, 8m, 16m, and 32m — 32m is
the maximum the JVM permits, which gives a Humongous threshold of only 16 MB. A single
decompressed 4000×2000 RGB buffer already exceeds that limit, so for deployments that
regularly process high-resolution images, Humongous allocations cannot be avoided regardless
of region size tuning. In those cases the Parallel GC default is the more appropriate choice.
For moderate image resolutions (roughly ≤ 2000×1000 px), increasing the region size can still
help. Use -XX:G1HeapRegionSize=32m as a starting point and monitor GC logs for Humongous
allocation events.
The following mitigation is effective regardless of image resolution:
com.coremedia.transform.throttle.permits=<n>- Limits the number of image transformations that may run concurrently, capping the peak native memory demand (in megabytes). The default is 1/4 of the configured heap size. Reducing this value lowers peak memory pressure at the cost of transformation throughput.


