cloudfoundry / cloudfoundry/java-buildpack

Support configurable initial/minimum heap size relative to (/as a percentage of) calculated Xmx

Open
#1,377 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
452
Forks
2.5k
Avg merge
14h 57m
Merged PRs (30d)
23

Description

In the 3.x line of the buildpack, config/open_jdk_jre.yml supported a memory_initials mapping, allowing the initial size of each memory region (heap, permgen, metaspace) to be configured as a percentage of its calculated maximum. (https://github.com/cloudfoundry/java-buildpack/blob/3.x/docs/jre-open_jdk_jre.md). This option no longer appears from v4.0 onward (2017), including the current Go-based v5.x buildpack.

Because -Xmx is only known at container start (it depends on the memory limit assigned to the app instance), we cannot set a matching or proportional -Xms value ourselves via JAVA_OPTS, because we'd need to know the calculated -Xmx ahead of time. In practice this means our JVMs start with a small default initial heap and grow it under load, causing avoidable heap-resize activity that didn't happen back when memory_initials was available.

Could memory_calculator support such an option again to set the initial heap size as a percentage of the calculated max heap? This would let us keep using the automatic memory calculation while avoiding heap growth pauses after startup.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the memory_calculator entry point and compare its current behavior with the 3.x config/open_jdk_jre.yml memory_initials mapping and linked documentation. The work is done when an option can set initial heap size as a percentage of the automatically calculated maximum heap without requiring a manually known Xmx.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, java
Domain
build-system, devops
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.