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
The CF java-buildpack explicitly sets the XX:ActiveProcessorCount [1] for an improved container support [2].
With OpenJDK 11.0.17 and 17.0.5 the cpu shares are no longer used to calculate the active processor count [3].
With this improvement in container support by OpenJDK, the explicit setting of ActiveProcessorCount by the buildpack seems to be redundant.
Would it be possible to change the buildpack to NOT set XX:ActiveProcessorCount for versions of OpenJDK >=11.0.17 and >=17.0.5 by default?
EDIT: it seems like it is still under discussion in the OpenJDK community whether this change ([3]) should be rolled back for releases 11 and 17, and only be kept for JDK19+. So it might be that the request only applies to a certain range, e.g. 17.0.5 to 17.x.
Reason for my request:
The JVM ergonomics (GC threads, etc.) and also thread pools of Frameworks/Apps are based on the active processor count, e.g. 64 CPUs instead of 1 CPU. This will cause a higher number of threads and stack memory usage. In addition depending on the container memory the GC algorithm switches from serial GC to G1 GC, which will have a much higher native/internal memory footprint. This can cause container OOMs. (we recently have observed some which are likely related to this problem)
-XX:ActiveProcessorCount overrules the flag -XX:+UseContainerCpuShares which was created to be used to revert to the previous behavior [4]. Thus, -XX:+UseContainerCpuShares cannot be used with the CF java-buildpack.
Since the OpenJDK JVM now (seemingly) handles container support better in this place, actively setting -XX:ActiveProcessorCount should no longer be required.
Feature (removal) Request
The CF java-buildpack explicitly sets the XX:ActiveProcessorCount [1] for an improved container support [2].
With OpenJDK 11.0.17 and 17.0.5 the cpu shares are no longer used to calculate the active processor count [3].
With this improvement in container support by OpenJDK, the explicit setting of ActiveProcessorCount by the buildpack seems to be redundant.
Would it be possible to change the buildpack to NOT set
XX:ActiveProcessorCount
for versions of OpenJDK>=11.0.17
and>=17.0.5
by default?EDIT: it seems like it is still under discussion in the OpenJDK community whether this change ([3]) should be rolled back for releases 11 and 17, and only be kept for JDK19+. So it might be that the request only applies to a certain range, e.g.
17.0.5 to 17.x
.Reason for my request:
The JVM ergonomics (GC threads, etc.) and also thread pools of Frameworks/Apps are based on the active processor count, e.g. 64 CPUs instead of 1 CPU. This will cause a higher number of threads and stack memory usage. In addition depending on the container memory the GC algorithm switches from serial GC to G1 GC, which will have a much higher native/internal memory footprint.
This can cause container OOMs. (we recently have observed some which are likely related to this problem)
-XX:ActiveProcessorCount
overrules the flag-XX:+UseContainerCpuShares
which was created to be used to revert to the previous behavior [4]. Thus,-XX:+UseContainerCpuShares
cannot be used with the CF java-buildpack.Since the OpenJDK JVM now (seemingly) handles container support better in this place, actively setting
-XX:ActiveProcessorCount
should no longer be required.I found a related issue in paketo buildpacks [5].
[1] lib/java_buildpack/jre/open_jdk_like_jre.rb#L70
[2] #650
[3] https://bugs.openjdk.org/browse/JDK-8281181
[4] https://bugs.openjdk.org/browse/JDK-8288367
[5] paketo-buildpacks/libjvm#136
Thanks for sharing your thoughts on this suggestion to remove the
-XX:ActiveProcessorCount
default setting for newer versions of OpenJDK 🙂The text was updated successfully, but these errors were encountered: