If you have any questions about how to structure your changes feel free to ping me over slack as I was the primary author of the new LIR support for barriers.

If you have any questions about how to structure your changes feel free to ping me over slack as I was the primary author of the new LIR support for barriers.

Thanks, Tom! I will do that whenever I get stuck or have questions. So far I'm making progress. Structurally, Shenandoah will be look like a mix of ZGC (for the load-barrier, even though I am modeling it as a Node that consumes the loaded value, instead of replacing the ReadNode altogether) and G1 (for the SATB parts), and likely Serial/Parallel for the card-table parts.

Sounds good. There's still some more work to finish out the switch to LIR only barriers but I think supporting G1 and ZGC covers the required strategies in a fairly pragmatic way.

@tkrodriguez can you please take another look at this. Once done, we can ask @davleopo and @gergo- to look at it.

I'll take a look.

Are the gate failures actual problems? It would be good to see a clean gate. Also, we should squash the history before committing.

Are the gate failures actual problems? It would be good to see a clean gate.

I don't know what those problems are. I fixed everything that looked related to my changes. Those failures look like infra problems, some volumes seem to have run out of memory or something. I doubt that it is related.

Also, we should squash the history before committing. Ok, I can do that - tomorrow.

@tkrodriguez There seem to be GHA failures that report SerialWriteBarriers not being Lowerable, coming from SubstrateVM. Could this be related to moving the barrier addition phase from mid- to low-tier? I don't think I have changed anything in SerialWriteBarrier or related code.

Yes this is something I mentioned in our slack discussions. Moving WriteBarrierAdditionPhase after LowTierLoweringPhase creates problems for GCs that still use snippets since they expect to be lowered by LowTierLoweringPhase. In the long term I would like it to be done there but I'm not sure how to bridge the gap. I've got an internal PR based on your branch that I'm testing and I was going to look into this.

The options are to conditionalize the placement of WriteBarrierAdditionPhase based on methods from BarrierSet but that's not available when constructing the suites. We could have early and late WriteBarrierAdditionPhase to handle each case during the transition but that's a bit ugly to me. Or we could beef up WriteBarrierAdditionPhase to perform any required lowering itself, though that might be a bit complicated. It would also complicate stuff like BarrierSetVerificationPhase and some barrier elimination that's part of enterprise.

I'm going to try putting appendPhase(new PlaceholderPhase<>(WriteBarrierAdditionPhase.class)); in both MidTier and LowTier and do the placeholder replacement based on the BarrierSet.

Yes this is something I mentioned in our slack discussions. Moving WriteBarrierAdditionPhase after LowTierLoweringPhase creates problems for GCs that still use snippets since they expect to be lowered by LowTierLoweringPhase. In the long term I would like it to be done there but I'm not sure how to bridge the gap. I've got an internal PR based on your branch that I'm testing and I was going to look into this.

The options are to conditionalize the placement of WriteBarrierAdditionPhase based on methods from BarrierSet but that's not available when constructing the suites. We could have early and late WriteBarrierAdditionPhase to handle each case during the transition but that's a bit ugly to me. Or we could beef up WriteBarrierAdditionPhase to perform any required lowering itself, though that might be a bit complicated. It would also complicate stuff like BarrierSetVerificationPhase and some barrier elimination that's part of enterprise.

I'm going to try putting appendPhase(new PlaceholderPhase<>(WriteBarrierAdditionPhase.class)); in both MidTier and LowTier and do the placeholder replacement based on the BarrierSet.

As far as I can see, it's only the SerialWriteBarrierNode which depends on snippets (is that right?). That should be relatively straightforward to implement without snippets and would look almost exactly like ShenandoahCardBarrierNode implementation - even a little simpler. I could work on implementing that, if you think that'd help.

It would be easy to convert the HotSpot serial barrier to LIR but native image uses snippets for its barriers and its serial barrier is non-trivial. So we'll need to live with this mixed model for a little while I think. I'm beginning to think we might just need an early and late phase. I think the way barriers for vector writes work, we might have to do barrier addition for them before LowTierLowering, or at least before VectorLoweringPhase, which is before FixReadsPhase.

It might be too much to try to resolve all these issues in this PR. Since Shenandoah is currently HotSpot only maybe it would be best to special case its barrier insertion. I'll will play some more with this to see what would be best.

It would be easy to convert the HotSpot serial barrier to LIR but native image uses snippets for its barriers and its serial barrier is non-trivial. So we'll need to live with this mixed model for a little while I think. I'm beginning to think we might just need an early and late phase. I think the way barriers for vector writes work, we might have to do barrier addition for them before LowTierLowering, or at least before VectorLoweringPhase, which is before FixReadsPhase.

It might be too much to try to resolve all these issues in this PR. Since Shenandoah is currently HotSpot only maybe it would be best to special case its barrier insertion. I'll will play some more with this to see what would be best.

I implemented barrier addition to trigger in both mid- and low-tier, and the BarrierSet implementation gets to choose which one (or both, if it wishes) is appropriate. This choice defaults to mid-tier, and can be overridden in implementations, like I did in ShenandoahBarrierSet. This way we get a clean gate :-)

Thanks. I'll see whether that works ok in our full gate. I'd tried something slightly different but the StageFlags makes it hard to be super flexible about when these phases run. I might be tempted to keep only the phase that actually does the work in the final suite.

Your fix works though I don't love some of the details. I'll just put comments on those places. I was able to get a clean internal gate with just minor changes in enterprise. I wasn't actually able to test Shenandoah because we don't have a labsjdk that includes it at the moment.

Overall I think this looks good. I've only lightly reviewed the actual shenandoah parts since I don't really know anything about how the collector works. A high level JavaDoc comment on each of your newly added classes would be appreciated.

@davleopo @gergo- I think it's in good shape for review.

LGTM

So I have working truffle entry point read barrier changes but that exposed a deeper problem. The current changes rely on running after FixReadsPhase or not having any floating reads but the economy configuration doesn't run FixReadsPhase. We're also not strict about never emitting FloatingReadNodes in the mode so some reads end up without a barrier because they are floating. We're moving towards enforcing no floating reads in economy but it's not how it works yet.

So I'm looking at moving the read barrier into the LIR so it matches the ZGC implemenation. This would also remove all the changes to where WriteBarrierAdditionPhase is run. The way I'm approaching this is changing the oop reading node to always return uncompressed oops when a read barrier is used, which avoids any dancing around with compression in the barrier itself. It is largely straightforward and is mostly passing the unit tests. I'm chasing a crash or two but I should have something later today that we can evaluate.

So I have working truffle entry point read barrier changes but that exposed a deeper problem. The current changes rely on running after FixReadsPhase or not having any floating reads but the economy configuration doesn't run FixReadsPhase. We're also not strict about never emitting FloatingReadNodes in the mode so some reads end up without a barrier because they are floating. We're moving towards enforcing no floating reads in economy but it's not how it works yet.

So I'm looking at moving the read barrier into the LIR so it matches the ZGC implemenation. This would also remove all the changes to where WriteBarrierAdditionPhase is run. The way I'm approaching this is changing the oop reading node to always return uncompressed oops when a read barrier is used, which avoids any dancing around with compression in the barrier itself. It is largely straightforward and is mostly passing the unit tests. I'm chasing a crash or two but I should have something later today that we can evaluate.

That sounds great, thank you! Let me know if I can help with anything!

That idea didn't really pan out as it would have required changes to FloatingReadNode that I didn't really want to make. So I'm looking into enforcing the rule that there should be no floating reads in economy mode. That's likely to be true soon as part of another PR but it's not being enforced there. It's mostly straightforward to enforce and we can resolve any conflicts in how it's done once we're ready to merge. I kind of wanted to push this kind of enforcement anyway, and this gives me a good reason.

I have a set of changes that disallow floating reads from reaching the backend which makes the read barrier strategy for shenandoah work in economy. It's not completely clear whether that will be pushed as part of this PR or if we might want to separate it. Could you rebase to the latest master? I need to update the CI tasks which recently changed. Once you've rebased I can update my internal PR and mirror that to github with my fixes on top. Then we can finish any required work there. Sound good?

I have a set of changes that disallow floating reads from reaching the backend which makes the read barrier strategy for shenandoah work in economy. It's not completely clear whether that will be pushed as part of this PR or if we might want to separate it. Could you rebase to the latest master? I need to update the CI tasks which recently changed. Once you've rebased I can update my internal PR and mirror that to github with my fixes on top. Then we can finish any required work there. Sound good?

Sounds good! I rebased my branch to latest master.

So I've taken your changes and applied some fixes including the changes to have only fixed reads in backend, and the combined PR is at #11941. The fix reads change will be addressed separately for clarity under #11942 and I will rebase once that merges. I can address Gergos final comments there but it seems like it's all working. I had a full clean gate including all benchmarks with shenanadoah last week though I had seem a crash or two during early testing so there might still be some problems lurking. Once it's all clean and ready I'll do a final squash since the history is getting very ugly. Does that sound all good?

So I've taken your changes and applied some fixes including the changes to have only fixed reads in backend, and the combined PR is at #11941. The fix reads change will be addressed separately for clarity under #11942 and I will rebase once that merges. I can address Gergos final comments there but it seems like it's all working. I had a full clean gate including all benchmarks with shenanadoah last week though I had seem a crash or two during early testing so there might still be some problems lurking. Once it's all clean and ready I'll do a final squash since the history is getting very ugly. Does that sound all good?

Yep, perfect! Thank you for your help!

I have rebased to master and incorporated most of Gergos suggestions but wasn't sure about the two I left unresolved. The new state is over at #11941. @rkennke maybe you could provide guidance on the last 2 unresolved comments and my last set of review comment commits?

I have rebased to master and incorporated most of Gergos suggestions but wasn't sure about the two I left unresolved. The new state is over at #11941. @rkennke maybe you could provide guidance on the last 2 unresolved comments and my last set of review comment commits?

I commented on Gergos comments, I don't think we can use tbz/tbnz because of the jump offset limitation. The second part of the comment can be deleted. Your commit looks fine. Thank you for taking care of all this!

This was merged under 3c7b5cb

@rkennke Thank you very much for all your work over half a year!

@fniephaus, @alina-yur could you please add this PR to the GraalVM Community Roadmap? I think it is worth being mentioned there.

Also, it seems that the GraalVM Community Roadmap view is a little bit out of sync, as it still mentions "GraalVM 25" which was released in September 2025 under "Upcoming Releases". Maybe you can fix that as well?

Hi @simonis, congrats on reaching the first milestone :)

The topic is already in the roadmap as #12237. I linked this PR there and moved the item to "In Progress". I also moved the 25 items to released, thank you for the suggestions.

Hi @simonis, congrats on reaching the first milestone :)

The topic is already in the roadmap as #12237. I linked this PR there and moved the item to "In Progress".

@alina-yur, #12237 is about porting the Shenandoah GC to Substrate VM / Native Imaeg. This change here, which indeed might be badly named, is about adding Shenandoah support to the Graal JIT compiler running on HotSpot (similar to [GR-27475] Add ZGC support which is on the roadmap as Add support for ZGC on HotSpot. So could you please add it to the roadmap as something like "Add support for Shenandoah on HotSpot" with the status "Done".

I also moved the 25 items to released, thank you for the suggestions.

Thanks for moving 25 to released. Do you know why the ordering is so strange. E.g. for me "GraalVM 25" is sorted between "GraalVM for JDK 17" and "22.3.0 Release" instead of appearing on top of the list?