From 9bbb189f9eda5b132983a6ee05dcd8c652be6e95 Mon Sep 17 00:00:00 2001
From: Damon Fenacci <damon.fenacci@oracle.com>
Date: Thu, 15 Jan 2026 16:53:25 +0100
Subject: [PATCH] JDK-8374852: revert comment change

---
 .../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 2fd5052630c..3b01e0f85a4 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. 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.
+            // 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, get replaced
+            // by TOP, and cause a failure in the matcher.
             return JLA.countPositives(bytes, -1, 42);
         } catch (Exception e) {
             return 0;