Inconsistent configuration between build time and run time initialized classes of netty

[zakkak]

Describe the bug

In #37347 we marked PlatformDependent for runtime (re)initialization. However there are still places were the (re)initialization has no effect because of classes using PlatformDependent in their static initializers being build time initialized. E.g.:

• https://github.com/netty/netty/blob/f9e20ac0490d2877c81def47a7d4046e06d9f410/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java#L116
• https://github.com/netty/netty/blob/d9850cd032e0dc4c05f3b1733b3ddf9461474abe/buffer/src/main/java/io/netty/buffer/PoolArena.java#L34
• https://github.com/netty/netty/blob/23c19b2b764d49437c49653121c8185130814033/codec/src/main/java/io/netty/handler/codec/compression/LzfEncoder.java#L43
• https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/common/src/main/java/io/netty/util/internal/CleanerJava9.java#L38
• https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/OpenSslX509TrustManagerWrapper.java#L60
• https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/buffer/src/main/java/io/netty/buffer/EmptyByteBuf.java#L49
• https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/common/src/main/java/io/netty/util/internal/CleanerJava6.java#L53 (although we probably don't care about this particular case since it's for legacy support)

This results in some parts of the code assuming something is always true while others depend on runtime configuration.

Expected behavior

All places in code should follow the same assumptions.

Actual behavior

Some parts of the code assume something is always true (or false) while others depend on runtime configuration to figure out the actual value.

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

Mandrel or GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

Detected while investigating #42903

[quarkus-bot]

/cc @Karm (mandrel), @cescoffier (netty), @franz1981 (netty), @galderz (mandrel), @jponge (netty), @radcortez (config)

[cescoffier]

@zakkak would marking these classes as re-initialized make sense? We do not want to limit too much our ability to pre-initialize at build time, but this would be reasonable. WDYT?

[zakkak]

@zakkak would marking these classes as re-initialized make sense?

Yes, that would resolve the issue if we really want to allow runtime configuration of Netty. If instead we want to limit netty configuration at build-time then we need to find another way to make the values consistent.

We do not want to limit too much our ability to pre-initialize at build time, but this would be reasonable. WDYT?

It depends on what we consider reasonable. The build-time initialization of some of these classes may be resulting in optimized code generation due to better dead code elimination (e.g. whether unsafe is available or not is decided at build-time). Similarly some static initializers of these classes are not trivial so they might add a bit of overhead at startup time. The impact of the former is hard to measure without some "targeted" benchmarsk, while the latter is easier to measure.

[cescoffier]

Similarly some static initializers of these classes are not trivial so they might add a bit of overhead at startup time.

Yeah, that's what I'm seeing. Unfortunately, the only way to determine whether it's "reasonable" is to do it and measure.