Open andrew-m-leonard opened 6 months ago
@andrew-m-leonard To be clear:
which is a slight performance enhancement to JVM startup.
Does this only affect java executions during the build process, or will it affect the resulting JVM that we ship when run somewhere other than CentOS7?
@andrew-m-leonard To be clear:
which is a slight performance enhancement to JVM startup.
Does this only affect java executions during the build process, or will it affect the resulting JVM that we ship when run somewhere other than CentOS7?
@sxa I believe (although I have no proof it provides any significant performance difference!) the JDK that we build, because the StandardCharsets UTF-8 and US_ASCII are not put in the default CDS classlist if they are not picked up during the classlist build due to them not being in the build environment.
but this fix https://github.com/openjdk/jdk/commit/d395ac287900f2c22739751e39831dea8a189b5c forces them into classlist for jdk-24+
Discussed in community call. There is not an expectation that we will fix this using a CentOS7 system given the restrictions referenced above. A preferable solution for the future would be to move to using a different (later) container for running the builds (For example https://github.com/adoptium/temurin-build/issues/3847). Deproritising for now.
jdk-23 has had a build update to support LC_ALL=C.UTF-8 as the build environment (https://github.com/openjdk/jdk/commit/d395ac287900f2c22739751e39831dea8a189b5c), this better aligns the shell commands default charsets. It also aligns better with the JVM bootstrap initialization of the StandardCharsets and does not force the immediate loading of the Aliases & Cache tables, which is a slight performance enhancement to JVM startup.
I don't believe we can construct a C.UTF-8 for Centos7 ..? So we may need to consider upgrading the build image OS to one that does?