JBP_CONFIG_OPEN_JDK_JRE memory calculator settings ignored

[stokpop]

Setting memory calculator tuning parameters via JBP_CONFIG_OPEN_JDK_JRE has no effect in the Go buildpack. The configuration appears to be silently ignored.

Context

After migrating from the Ruby buildpack to the Go buildpack, apps that ran fine in a 750M container fail at startup with:

required memory 1269289K is greater than 750M available for allocation:
  -XX:MaxDirectMemorySize=10M, -Xmx512M, -XX:MaxMetaspaceSize=233001K,
  -XX:ReservedCodeCacheSize=240M, -Xss1M x 250 threads

This seems to be caused by the v4 memory calculator now including a user-pinned -Xmx in its total memory check (v3 did not) — see also cloudfoundry/java-buildpack#997 for background on the v3→v4 upgrade. A mitigation might be to reduce stack_threads via JBP_CONFIG_OPEN_JDK_JRE — but this appears to have no effect.

Expected behaviour

env:
  JBP_CONFIG_OPEN_JDK_JRE: '{ memory_calculator: { stack_threads: 50 } }'

Should result in --thread-count=50 passed to the memory calculator (as documented and as worked in the Ruby buildpack). Reducing from 250 → 50 threads saves 200M of stack, which would make the 750M container viable again.

Actual behaviour

The memory calculator always uses the default of 250 threads regardless of the setting.

Suspected root cause

Two issues in src/java/jres/memory_calculator.go:

1. LoadConfig() appears not to be called during Supply() or Finalize().
2. Even if called, LoadConfig() reads non-standard MEMORY_CALCULATOR_STACK_THREADS / MEMORY_CALCULATOR_HEADROOM env vars rather than parsing JBP_CONFIG_OPEN_JDK_JRE.

Suggested fix

• Parse JBP_CONFIG_OPEN_JDK_JRE in LoadConfig() using the standard CF YAML format.
• Call LoadConfig() at the start of Supply() (before class counting), so both class_count and stack_threads overrides take effect in time.
• Supported keys: stack_threads, class_count, headroom.

Related

• Migration notes should be updated to reflect the memory calculator impact — teams migrating from the Ruby buildpack may be surprised by startup failures.

Workaround

None found. MEMORY_CALCULATOR_STACK_THREADS might appear to be an alternative env var, but since LoadConfig() appears not to be called, it seems equally ignored.