On Fri, 8 May 2026 14:39:29 GMT, Joel Sikström <[email protected]> wrote:
>> Hello, >> >> This PR fixes an issue in `JVM_IHashCode` where we don't handle an exception >> occurring in the Java call to `ValueObjectMethods.valueObjectHashCode`. If >> an exception is thrown, we still proceed to install the (bad) hashcode that >> is based on a return value which is garbage data. >> >> To fix this, we should make sure to return if there is a pending exception. >> >> @xmas92 came up with a smart approach to encapsulate the behavior of >> wrapping an exception in an internal error into a separate helper, which is >> implemented in this PR as well. I've adapted other similar places where we >> wrap exceptions like this as well. These use-cases are all >> Valhalla-specific, so makes sense to change here IMO. >> >> Testing: >> * Running Oracle's tier1-4 >> * Test reproducer that fails before (installing a bad hashcode), and >> succeeds with the changes in this PR (never installs a bad hashcode). >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Joel Sikström has updated the pull request incrementally with one additional > commit since the last revision: > > Add regression test by @arraying test/hotspot/jtreg/runtime/valhalla/inlinetypes/HashOverflowTest.java line 32: > 30: * @enablePreview > 31: * @compile HashOverflowTest.java > 32: * @run main/othervm -Xint -Xss256K If this has to run with -Xint should we exclude from e.g. Xcomp runs, or maybe just mark this as flagless? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2410#discussion_r3216676230
