From 52a3681555c658e27b5869feab2fce081b81e0f4 Mon Sep 17 00:00:00 2001
From: Damon Fenacci <damon.fenacci@oracle.com>
Date: Thu, 15 Jan 2026 16:49:06 +0100
Subject: [PATCH] JDK-8374852: correct  comment and make more concise

---
 .../compiler/intrinsics/string/TestRangeCheck.java     | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java b/test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java
index 139986b9810..2fd5052630c 100644
--- a/test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java
+++ b/test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java
@@ -54,11 +54,11 @@ public class TestRangeCheck {
             // to the `StringCoding::countPositives0` intrinsic.
             // `countPositives` validates its input using
             // `Preconditions::checkFromIndexSize`, which also maps to an
-            // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not
-            // know about the explicit range checks, and does not cut off the
-            // dead code. As a result, an invalid value (e.g., `-1`) can be fed
-            // as input into the `countPositives0` intrinsic, got replaced
-            // by TOP, and cause a failure in the matcher.
+            // intrinsic. If `checkFromIndexSize` is not inlined,
+            // C2 lacks knowledge of the explicit range checks, so an invalid
+            // index (e.g., -1) can reach `countPositives0`. The intrinsic then
+            // replaces the out‑of‑range data input with TOP, preserving the
+            // control flow, which leads to a matcher failure.
             return JLA.countPositives(bytes, -1, 42);
         } catch (Exception e) {
             return 0;