[lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail with --enable-preview [v3]

Marc Chevalier mchevalier at openjdk.org
Fri Dec 19 13:30:41 UTC 2025


> Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time.
> 
> There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop.
> 
> The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have
> 
> value class MyValue {
>     int x;
> }
> class C {
>     MyValue v;  // assumed flat.
> }
> 
> the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset.
> 
> I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array.
> 
> The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That matches what we do in `void ciField::i...

Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge remote-tracking branch 'origin/lworld' into JDK-8372700
 - review
 - Solving conflict with myself: Merge remote-tracking branch 'lworld' into JDK-8372700
 - Un-problemlist
 - Merge remote-tracking branch 'origin/lworld' into JDK-8372700
 - Cleanup
 - Cleanup
 - Fix header size
 - damn is_null_or_zero assumes is_valid
 - Merge remote-tracking branch 'origin/lworld' into JDK-8372700
 - ... and 6 more: https://git.openjdk.org/valhalla/compare/69399ced...b64ff8ce

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

Changes: https://git.openjdk.org/valhalla/pull/1826/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1826&range=02
  Stats: 301 lines in 20 files changed: 280 ins; 7 del; 14 mod
  Patch: https://git.openjdk.org/valhalla/pull/1826.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1826/head:pull/1826

PR: https://git.openjdk.org/valhalla/pull/1826


More information about the valhalla-dev mailing list