[master] RFR: 8347710: [Lilliput] Implement 4 byte headers [v8]
Andrew Dinn
adinn at openjdk.org
Mon Jan 27 11:02:16 UTC 2025
On Mon, 27 Jan 2025 10:34:38 GMT, Andrew Haley <aph at openjdk.org> wrote:
> Is there ever a time when we have an acquiring load on a narrow klass pointer?
That's a good question! This predicate was added to handle volatile instance field loads (there is a similar set of cases for volatile stores). I believe I unthinkingly allowed for the possibility of the acquire case for Klass and NKlass loads (likewise stores) when I first added the rules that used the predicate (I think I just blindly changed all the rules that did a load/store). At that stage the test was done by traversing the graph but even then it was probably always going to fail for a Klass load/store.
In the current implementation the predicate is implemented by checking field `_mo` of the relevant `LoadNode` which is set at node create and does not appear ever to get reset. Looking at the opto sources it appears that `LoadKlassNode` and `LoadNKlassNode` only ever seem to be created created with `_mo == unordered`. So, I think the Klass load/store rules which check for acquire/release semantics can be dropped.
It would be worth seeking confirmation of that from @rwestrel who was the one who changed the implementation so it relied on the `_mo` fields in `Load/StoreNode`.
-------------
PR Review Comment: https://git.openjdk.org/lilliput/pull/193#discussion_r1930339522
More information about the lilliput-dev
mailing list