-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
P4
-
None
-
Affects Version/s: None
-
Component/s: hotspot
-
x86_64, aarch64
-
linux, os_x, windows
This is a bug observed in current 11u and 17u versions. It has been observed on x64 and aarch64, and on Mac OS, Linux, and Windows operating systems.
Certain kinds of large classes, such as those created by the Chicory WASM-to-Java bytecode generation process, have methods that when inlined, interact with the compiler in a way which appears to cause some intrinsics (for example `Integer.compareUnsigned()`) to return incorrect values under some set of repeatable (but unknown) circumstances.
The problem does not seem to occur in later JDK versions (i.e. 21 or 25), but it is unclear whether this is due to a bug having been fixed (which could possibly be backported), or due to a different choice of compiler defaults which then masks the problem, or due to some other factor.
The problem can usually be worked around by using `-XX:CompileCommand=dontinline,...` to prevent the method which contains the intrinsic call from being inlined. See this example (comment): https://github.com/dylibso/chicory/pull/1135#issuecomment-3799777088
The manifestation of this issue is that intrinsic operations sometimes appear to return completely wrong values. In the case of Chicory, this appears as test failures showing out-of-range array indexes being used. The failure seems to always appear in the same location.
This Chicory CI run shows the effect of the problem: http://github.com/dylibso/chicory/actions/runs/21347680821/job/61438242339?pr=1135#step:6:1770 (note that in this context, "memory access" is referring to WASM memory, which is actually an array access).
Certain kinds of large classes, such as those created by the Chicory WASM-to-Java bytecode generation process, have methods that when inlined, interact with the compiler in a way which appears to cause some intrinsics (for example `Integer.compareUnsigned()`) to return incorrect values under some set of repeatable (but unknown) circumstances.
The problem does not seem to occur in later JDK versions (i.e. 21 or 25), but it is unclear whether this is due to a bug having been fixed (which could possibly be backported), or due to a different choice of compiler defaults which then masks the problem, or due to some other factor.
The problem can usually be worked around by using `-XX:CompileCommand=dontinline,...` to prevent the method which contains the intrinsic call from being inlined. See this example (comment): https://github.com/dylibso/chicory/pull/1135#issuecomment-3799777088
The manifestation of this issue is that intrinsic operations sometimes appear to return completely wrong values. In the case of Chicory, this appears as test failures showing out-of-range array indexes being used. The failure seems to always appear in the same location.
This Chicory CI run shows the effect of the problem: http://github.com/dylibso/chicory/actions/runs/21347680821/job/61438242339?pr=1135#step:6:1770 (note that in this context, "memory access" is referring to WASM memory, which is actually an array access).