apache
CASSANDRA-18831 Add JDK21 support
Add JDK21 support
Patch by jmckenzie; reviewed by TBD for CASSANDRA-18831
FYI if you want to retain a max tenuring threshold of 1, you can specify -XX:ZTenuringThreshold=1 with generational ZGC. But honestly it will probably figure things out automatically anyway.
k, signposting intent here @ekaterinadimitrova2 and @michaelsembwever:
- I'll get internal CI working w/this branch and JDK21, so then I can...
- revert the experimental bytebuddy again and see how it behaves (think I erroneously attributed failures to it on subsequent run that weren't it) w/out having an external "please run CI for me" dep
- I'll double-check to make sure I captured all the changed default GC params (that was work that Marcus did I wasn't involved in and it got absorbed into the diff I then upstreamed; I need to more deeply familiarize myself with that changeset to make sure I revert it), and finally
- I'll work through any and all test failures, ensuring any erroneous test changes (haven't looked at the code yet; chaotic Monday) are addressed, with a bias toward reverting to baseline if possible and passing.
I'm going to set this PR "on deck" for a week or two to address another priority, then will work through all this in a closed loop and surface if I get blocked on or need a 2nd pair of eyes on anything. That way we can break out of the long-async cycles we've been having on review / integration on this branch and hopefully push it across the line.
Hello, Thanks for the work on adding JDK 21 support! I’ve been following this PR with interest as someone outside the project and was wondering if there’s any update or expected timeline for when it might be reviewed or merged.
Appreciate all the work the team is doing on Cassandra!
any update or expected timeline for when it might be reviewed or merged
The hold up is CI validation. I have 1 pipeline left (python upgrade dtests) to get working on our internal CI infrastructure then it should only be a couple of weeks to burn down test failures. The code as written here is functionally identical to what we're running internally on a fork on a very large fleet w/all CI passing so if you wanted to create a build from this patch to tinker with, you should be in a very solid place.
I'm going to be traveling next week and we have the community over code conference coming up in a month so it's not an ideal season for keeping things moving along but I certainly haven't forgotten about this work, it just got shuffled a bit in priorities but I'm almost dug out from under things.
--add-opens/--add-exports flags are FIXME markers signifying non-portable code that may break with any release. The more there are, the likelier the code is to break. By all accounts, a program with 30 such flags shouldn't work at all unless it's specifically hand-crafted for that release. Even if these changes are necessary yet the software miraculously works across versions, it can't work for long. But this project works on JDK 17, so that this change works on 21 tells me these flags are largely unnecessary or that the fixes they require aren't so complicated.
Without such flags, a piece of software is highly likely to work, unchanged, on future JDK releases for a long time, enjoying performance and observability improvements for free. But every single one of them that is removed can contribute to the project's stability and portability, so I would recommend taking the time to make sure they're really needed.
But this project works on JDK 17, so that this change works on 21 tells me these flags are largely unnecessary or that the fixes they require aren't so complicated.
https://github.com/apache/cassandra/blob/trunk/conf/jvm17-server.options#L69
https://github.com/apache/cassandra/blob/trunk/conf/jvm17-server.options#L69
Ah. In that case, the code is living on borrowed time and has just been lucky. Every release increases the chance of things breaking. Remember that the reason for encapsulation of JDK internals (or one of the several reasons) is to give the JDK more freedom to change internals more liberally, and we've been taking advantage of the freedom. The pace of changes to internals is expected to continue growing.
I had a look at a couple of uses of internal access, and they now have standard replacements (albeit in JDK 22 and on).
@pron - you are not wrong. Please check the discussion below: https://lists.apache.org/[email protected]:2022-9:jdk%20internals
Also, I would like to mention that on JDK17, we reduced the number of add-opens and add-exports, especially with the update of the jamm library and other code changes during the upgrade. We will be happy to continue improving things when there is a chance.
I had a look at a couple of uses of internal access, and they now have standard replacements (albeit in JDK 22 and on).
That is great. Please feel free to open tickets with your findings. It would be even better if you had patches, but even just tickets would be great. Thank you for your input here. Highly appreciated
