On Thu, 27 Mar 2025 11:30:11 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> I'm breaking this change out as a separate improvement, since it will not be >> generally possible to adjust these limits on the j.u.c primitives since they >> might already use a backing `long` to pack in information which needs to be >> updated atomically (would require 128-bit atomics to widen them, and it >> still infeasible to change return types of pre-existing APIs). > > We'll need to double check serialization compatibility as the "sync" field is > in the serial form. > @AlanBateman I was able to serialize a RRWL created before this patch and > deserialize it after this patch. Okay, so we serialize a FairSync or NonfairSync when they are a AQS. When we deserialize, they will be a AQLS. It works because the internal classes haven't been renamed. If either internal class were to be renamed then we've get a CNFE. So I think what you have is okay and there's no compatibility or interop issue created at this time. However, having "sync" in the serial form is technical debt that will surface at some point. Ideally's RRWL's serial form would have something else to persistent the "fairness" bit as that is also it needs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24261#issuecomment-2771959548
