[PR] Use Java 21 for pipeline dialect modules [shardingsphere]

["sandynz (via GitHub)" <gi...@apache.org>]

sandynz opened a new pull request, #38553:
URL: https://github.com/apache/shardingsphere/pull/38553

   
   Changes proposed in this pull request:
     - Use Java 21 for pipeline dialect modules
   
   ---
   
   Before committing this PR, I'm sure that I have checked the following options:
   - [ ] My code follows the [code of conduct](https://shardingsphere.apache.org/community/en/involved/conduct/code/) of this project.
   - [ ] I have self-reviewed the commit code.
   - [ ] I have (or in comment I request) added corresponding labels for the pull request.
   - [ ] I have passed maven check locally : `./mvnw clean install -B -T1C -Dmaven.javadoc.skip -Dmaven.jacoco.skip -e`.
   - [ ] I have made corresponding changes to the documentation.
   - [ ] I have added corresponding unit tests for my changes.
   - [ ] I have updated the Release Notes of the current development version. For more details, see [Update Release Note](https://shardingsphere.apache.org/community/en/involved/contribute/contributor/)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Use Java 21 for pipeline dialect modules [shardingsphere]

["sandynz (via GitHub)" <gi...@apache.org>]

sandynz merged PR #38553:
URL: https://github.com/apache/shardingsphere/pull/38553


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Use Java 21 for pipeline dialect modules [shardingsphere]

["sandynz (via GitHub)" <gi...@apache.org>]

sandynz commented on PR #38553:
URL: https://github.com/apache/shardingsphere/pull/38553#issuecomment-4125175611

   # JVM Options Cleanup for Java 21
   
   This PR updates the ShardingSphere Proxy startup scripts (`start.sh` / `start.bat`) and the E2E fixture script to be Java 21-only, removing all legacy version-specific branches and replacing outdated JVM flags.
   
   ---
   
   ## What Changed and Why
   
   ### Minimum Java Version Enforcement
   
   Added an explicit Java 21 version check at startup. If the detected JVM is below 21, the script exits immediately with a clear error message rather than failing with a cryptic JVM error later.
   
   ### Removed: Version-Specific Branches (`int_version` logic)
   
   The original scripts maintained separate `VERSION_OPTS` blocks for Java 8, 11, and 17. Since Proxy now requires Java 21, this branching is dead code and has been replaced with a single unified configuration.
   
   ### Removed: Incompatible JVM Flags
   
   The following flags were removed because they are **no longer recognized in Java 21** and cause JVM startup failure:
   
   | Flag | Reason for Removal |
   |------|--------------------|
   | `-XX:+UseConcMarkSweepGC` | CMS GC was deprecated in Java 9 and **removed in Java 14**. Passing it in Java 21 causes immediate JVM exit. |
   | `-XX:+CMSParallelRemarkEnabled` | CMS-specific, removed along with CMS. |
   | `-XX:+UseCMSInitiatingOccupancyOnly` | CMS-specific, removed along with CMS. |
   | `-XX:CMSInitiatingOccupancyFraction=70` | CMS-specific, removed along with CMS. |
   | `-XX:+UseFastAccessorMethods` | Became a no-op in Java 10, removed in Java 11. |
   | `-XX:+AggressiveHeap` | Deprecated in Java 11, removed in Java 14. Behavior was unpredictable in container environments. |
   | `-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler` | Was used to enable Graal JIT in OpenJDK 11. No longer appropriate in Java 21 where the JIT landscape has changed. |
   | `-Xmn1g` (fixed young gen size) | **Incompatible with G1GC's design.** G1 dynamically manages heap regions across generations; fixing `-Xmn` prevents G1 from self-tuning its young generation size, which works against `MaxGCPauseMillis`. |
   | `-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap` | Java 8 experimental container memory awareness. Built into the JVM from Java 10 onward; `-XX:InitialRAMPercentage` etc. are available directly. |
   
   ### New: Java 21 GC Configuration
   
   ```
   -XX:+UseG1GC
   -XX:MaxGCPauseMillis=200
   -XX:+UseStringDeduplication
   -XX:+SegmentedCodeCache
   ```
   
   ---
   
   ## GC Selection: G1GC vs ZGC
   
   This was the main design decision. Both are valid production GCs in Java 21, so here is the reasoning.
   
   ### Why Not ZGC?
   
   ZGC (specifically Generational ZGC, which is the default in Java 21) achieves sub-millisecond pause times by doing virtually all GC work concurrently alongside application threads. The trade-offs are:
   
   1. **Higher sustained CPU usage.** Because GC threads run concurrently with the application, they compete for CPU time. For a proxy that does continuous SQL parsing and routing computation, this contention can reduce throughput under load.
   
   2. **No `UseStringDeduplication` support.** ZGC does not implement String deduplication. For ShardingSphere Proxy, a significant portion of live heap consists of repeated strings: SQL keywords, column names, table names, routing keys, and JDBC result set values. G1's deduplication removes these redundant `byte[]` backing arrays during concurrent marking, which meaningfully reduces heap pressure.
   
   3. **Load barrier overhead.** ZGC uses colored pointers and load barriers, adding a small cost to every object read. For result set iteration and metadata lookups this overhead accumulates.
   
   4. **The pause advantage is diluted by upstream latency.** The end-to-end latency of a proxied query is dominated by network round-trips and actual database execution time (typically 10ms–1s+). A G1 pause target of 200ms is not the primary latency driver in this workload, so the sub-millisecond guarantee of ZGC provides limited practical benefit for most deployments.
   
   ### Why G1GC?
   
   - **Balanced throughput and latency** with a configurable pause target, well-suited to a middleware workload that is neither throughput-only nor ultra-low-latency.
   - **String Deduplication** (`-XX:+UseStringDeduplication`) is G1-exclusive and reduces heap fragmentation caused by repeated strings common in JDBC workloads.
   - **Mature and widely observed.** G1 has a rich ecosystem of monitoring tools (GC logs, JFR, heap analyzers), making it easier to diagnose issues in production.
   - **Lower CPU overhead** compared to ZGC, which matters for CPU-bound SQL parsing paths.
   
   ### When ZGC Makes Sense Here
   
   If your deployment has strict tail-latency SLAs (p99 < 10ms), ample CPU headroom (8+ cores), and a large heap (8g+), ZGC is a reasonable alternative. To switch, replace `VERSION_OPTS`:
   
   ```bash
   VERSION_OPTS="-XX:+UseZGC -XX:+ZGenerational -XX:+SegmentedCodeCache"
   ```
   
   ---
   
   ## Retained Flags (with rationale)
   
   | Flag | Rationale |
   |------|-----------|
   | `-XX:MaxGCPauseMillis=200` | Instructs G1 to target 200ms max pause. G1 dynamically sizes the young generation to meet this goal. Lowering it (e.g. to 50ms) increases GC frequency and reduces throughput without meaningful latency benefit for this workload. |
   | `-XX:+UseStringDeduplication` | G1 identifies String objects with identical content during concurrent marking and consolidates their backing arrays. Beneficial for Proxy's SQL/metadata string-heavy heap. |
   | `-XX:+SegmentedCodeCache` | Splits the JIT code cache into segments by code type (non-method, profiled, non-profiled). Reduces GC scan scope and improves JIT eviction efficiency — relevant for Proxy's large set of hot SQL parsing paths. |
   | `-XX:+DisableExplicitGC` | Ignores `System.gc()` calls from third-party libraries (notably some Netty internals), preventing unintended full GC pauses. |
   | `-XX:AutoBoxCacheMax=4096` | Extends the `Integer` cache beyond the default `[-128, 127]` range. Reduces short-lived Integer allocations from shard key arithmetic and row count handling. |
   | `-XX:+UseNUMA` | NUMA-aware allocation on multi-socket machines. No-op on single-socket or container environments. |
   | `-XX:LargePageSizeInBytes=128m` | Enables large page hints where the OS supports it, reducing TLB misses. Silently ignored when not supported. |
   | `-Xss1m` | Per-thread stack size. The default (512k) can be insufficient for deep SQL parse tree recursion. 1m is a safe value for Proxy's parsing workload. |
   | `-XX:InitialRAMPercentage=80.0` / `-XX:MinRAMPercentage=80.0` / `-XX:MaxRAMPercentage=80.0` | Container-aware heap sizing. When running inside Docker (detected via `IS_DOCKER`), the heap is set to 80% of the container memory limit rather than using fixed `-Xmx`/`-Xms` values. |
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org