You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Integrate memory calculator v4 into runtime startup command
Implement Ruby buildpack parity by invoking memory calculator at container
runtime to calculate optimal JVM memory settings based on available memory.
Key changes:
- Add MemoryCalculatorCommand() interface method to all JRE implementations
to return shell command snippet for runtime memory calculation
- Update memory calculator to use v4.x double-dash flag format:
--total-memory, --loaded-class-count, --thread-count, --head-room,
--jvm-options (replacing v3.x single-dash format)
- Remove --pool-type flag (not used in v4.x)
- Prepend memory calculator command to container startup in release.yml
- Add base JAVA_OPTS: -Djava.io.tmpdir, -XX:ActiveProcessorCount,
-Djava.ext.dirs (Ruby buildpack parity)
- Escape startup command with single quotes in YAML to preserve shell
special characters ($, quotes, etc.)
- Use default class count (6,300) when class counting fails or returns 0
(v4 calculator requires this parameter)
Integration test updates:
- Reduce memory settings to fit within 1G container limit used by tests
- Memory calculator v4 has stricter defaults (240M code cache, 250 threads)
compared to v3.x used by Ruby buildpack
- Updated 8 integration tests with reduced heap (-Xmx384m or -Xmx256m),
smaller code cache (-XX:ReservedCodeCacheSize=120M), and reduced thread
stack (-Xss512k)
The memory calculator now runs inline in startup command (after profile.d
scripts assemble JAVA_OPTS) to read runtime $MEMORY_LIMIT and calculate
optimal memory flags, matching Ruby buildpack behavior.
All 99 integration tests pass.
0 commit comments