RFR: 8359412: Template-Framework Library: Operations and Expressions

Emanuel Peter epeter at openjdk.org
Thu Sep 11 05:22:18 UTC 2025


Impliementing ideas from original draft PR: https://github.com/openjdk/jdk/pull/23418 ([Exceptions](https://github.com/openjdk/jdk/pull/23418/files#diff-77e7db8cc0c5e02786e1c993362f98fabe219042eb342fdaffc09fd11380259dR41), [ExpressionFuzzer](https://github.com/openjdk/jdk/pull/23418/files#diff-01844ca5cb007f5eab5fa4195f2f1378d4e7c64ba477fba64626c98ff4054038R66)).

Specifically, I'm extending the Template Library with `Expression`s, and lists of `Operations` (some basic Expressions). These Expressions can easily be nested and then filled with arguments, and applied in a `Template`.

Details, in **order you should review**:
- `Operations.java`: maps lots of primitive operators as Expressions.
- `Expression.java`: the fundamental engine behind Expressions.
- `examples/TestExpressions.java`: basic example using Expressions, filling them with random constants.
- `tests/TestExpression.java`: correctness test of Expression machinery.
- `compiler/igvn/ExpressionFuzzer.java`: expression fuzzer for primitive type expressions, including input range/bits constraints and output range/bits verification.
- `PrimitiveType.java`: added `LibraryRNG` facility. We already had `type.con()` which gave us random constants. But we also want to have `type.callLibraryRNG()` so that we can insert a call to a random number generator of the corresponding primitive type. I use this facility in the `ExpressionFuzzer.java` to generate random arguments for the expressions.
- `examples/TestPrimitiveTypes.java`: added a `LibraryRNG` example, that tests that has a weak test for randomness: we should have at least 2 different value in 1000 calls.

If the reviewers absolutely insist, I could split out `LibraryRNG` into a separate RFE. But it's really not that much code, and has direct use in the `Expression` examples.

**Future Work**:
- Use `Expression`s in a loop over arrays / MemorySegment: fuzz auto-vectorization.
- Use `Expression`s to model more operations:
  - `Vector API`, more arithmetic operations like from `Math` classes etc.
- Ensure that the constraints / checksum mechanic in `compiler/igvn/ExpressionFuzzer.java` work, using IR rules. We may even need to add new IGVN optimizations. Add unsigned constraints.
- Find a way to delay IGVN optimizations to test worklist notification: For example, we could add a new testing operator call `TestUtils.delay(x) -> x`, which is intrinsified as some new `DelayNode` that in normal circumstances just folds away, but under `StressIGVN` and `StressCCP` it can at arbitrary times in CCP and IGVN narrow its type or fold away. Initially, it outputs the `bottom_type`, no matter the input type. Eventually, we can progressively update the output to be narrower, as long as it still contains the input type. And at some point fold it away. Each time, this should trigger worklist notification, and could trigger optimizations. If there is a bug, IGVN / CCP verification could catch it.

-------------

Commit messages:
 - fix whitespaces
 - LibraryRNG example
 - fix bug
 - documentation
 - improve expression fuzzer
 - wip constraints
 - add more comments
 - wip test cmp
 - test refactoring
 - handle non-deterministic results
 - ... and 15 more: https://git.openjdk.org/jdk/compare/02fe095d...0709731a

Changes: https://git.openjdk.org/jdk/pull/26885/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26885&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359412
  Stats: 1702 lines in 7 files changed: 1702 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26885.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26885/head:pull/26885

PR: https://git.openjdk.org/jdk/pull/26885


More information about the hotspot-compiler-dev mailing list