Make metaspace/class count adjustable by other buildpacks

[dmikusa]

What happened?

The memory calculator decides the metaspace settings for the application. It does so based on class count. This often works, but it will sometimes not work for particular types of apps or for particular Java agents. In these cases, additional tuning would be required by the user (basically to override and set metaspace).

• What were you attempting to do?

It would be helpful if there is an interface such that buildpacks can adjust and contribute to the class count or value that the memory calculator will determine. This would allow for dynamic changes, like if a Java agent requires an additional 10% metaspace memory or if a particular application type requires more metaspace.

In addition, because the class counting occurs in the JVM provider buildpack & libjvm, it happens early in the buildpack cycle, so if you have a buildpack that provides a Java agent and it runs after the JVM provider buildpack which is very likely, then the agent isn't taken into the class count. Thus the agent would need a way to augment the class count.

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

[dmikusa]

At present, we use an internal variable BPI_JVM_CLASS_COUNT to communicate the class count which is determined by the buildpack when the buildpack runs to the memory calculator which runs in the launch container prior to the application starting up.

libjvm/jre.go

Lines 99 to 103 in 603755c

	if c, err := count.Classes(layer.Path); err != nil {
	return libcnb.Layer{}, fmt.Errorf("unable to count JVM classes\n%w", err)
	} else {
	layer.LaunchEnvironment.Default("BPI_JVM_CLASS_COUNT", c)
	}

This variable is set as DEFAULT so it could be overwritten by another buildpack, however, it's only set a launch time so subsequent buildpacks would need to blindly overwrite it. They could not read the value calculated and increase it.

There is probably room for a richer integration here:

• minimally, we could make BPI_JVM_CLASS_COUNT build + launch, that way it is visible at build. Then an author could read and update that value.
• we might also look at adding an additional variable like BPI_JVM_AGENT_CLASS_COUNT where the memory calculator would take both into account
• we could look at adding an additional environment variable like BPI_JVM_CLASS_HEADROOM that would bump up the metaspace size by an extra percent. Instead of basing off the class count, this would take the memory calculator's metaspace value and increase it by the given percent. If memory calculator determined it needs 75M of metaspace, you could then at a value of 20 which would increase the value by 20% to 90M.