On Wed, 22 Jul 2026 21:22:49 GMT, Shiv Shah <[email protected]> wrote:
> serviceability/sa/ClhsdbLongConstant.java asserts an exact value for > VM_Version::CPU_SHA in checkForTruncation(). CPU_SHA is a feature-flag bit > index in vm_version_x86.hpp whose value shifts whenever a CPU feature is > added, so the hardcoded expectation goes stale and the test fails (it has > already been bumped once, and the in-file comment lists yet another value). > > This check exists only to confirm the `longConstant` output was not > truncated, using CPU_SHA as a sentinel that appears late in the output, the > exact value is irrelevant to that purpose. SA reads the value correctly from > the VM in every case. > > Change checkForTruncation() to verify the constant is present with a > parseable long value (checkLongValuePresent) instead of asserting a specific > number, so the check no longer breaks on every feature-flag change. The > markWord::hash_mask_in_place assertion is unchanged, since that value is > derived from a stable definition. > > Testing: serviceability/sa/ClhsdbLongConstant.java (x64). > > > > > > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Why the test fails only in container/docker environment? Why no failures in jdk CI? ------------- PR Comment: https://git.openjdk.org/jdk/pull/32017#issuecomment-5061569840
