[crac] RFR: 8354679: [CRaC] jdk.crac.management makes JdkManagementCheckSince fail

Timofei Pushkin tpushkin at openjdk.org
Tue Apr 22 07:21:03 UTC 2025


On Tue, 22 Apr 2025 06:57:50 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> OK, I thought that we could somehow preserve the oldest CRaC JDK version where the symbol appeared. But we don't need to change the taglet on too many places, so let's use this as is.

Symbols are fixed after GA so after GA they'll be preserved. But between rampdown and GA we'll need to be updating them (only the version that has not yet been GA-ed) when they are updated upstream.

Example for JDK 26:
1. 25 rampdown happens, 26 is created and symbols for 25 along with it — when merging this, we'll take the new 25 symbols and run the script to update them from the last 25-CRaC build.
2. 25's symbols get updated — when merging this, we'll overwrite our 25's symbols with the incoming ones, then run the script again to update them with the last 25-CRaC build (the same build as in step one), then fixup the symbols manually to remove the changes unrelated to CRaC (there will be such changes because the last 25-CRaC build will be based on an older 25 than the updated symbols). This step can happen a few times.
3. 25 GA happens — after this moment 25's symbols are fixed, we won't need to touch them ever again.

> That sounds useful, but we don't need to merge changes out-of-band, this PR is good as it is. Let's integrate this and use the -ignoreSince the next time this code needs updating anyway.

I was proposing to wait until that change gets merged-in. I believe we need to decide now: we either merge this PR and start generating CRaC symbols from now on or wait for the `SinceChecker` update that should allow us to continue without generating the symbols (I actually need to try this locally by cherry-picking to see how it works before we decide). It will be weird if now we start generating the symbols but then we suddenly stop.

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

PR Comment: https://git.openjdk.org/crac/pull/225#issuecomment-2820335231


More information about the crac-dev mailing list