[GR-77163] Safely publish object type id cache.#14006
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
failing: Multi type state with single type.
It happened in bytecode-sensitive subtraction. That code builds result object arrays using a cached int[] of object type IDs from ContextSensitiveMultiTypeState.getObjectTypeIds(). The cache was lazily initialized and stored in a plain field. In parallel analysis, another worker thread could observe the array reference without a proper publication edge, so it was not guaranteed to see the filled array contents.
If stale/default type IDs were read, subtraction could keep/remove the wrong objects, then try to construct a MultiTypeState even though the resulting bitset had only one type, triggering the assertion.
Implemented change
I changed ContextSensitiveMultiTypeState.objectTypeIds to volatile.
That makes the lazy cache safely published: the thread that fills the array writes all elements first, then publishes the reference through a volatile write. Other threads reading the non-null volatile reference are guaranteed to see the initialized contents. No synchronization is needed because duplicate initialization is harmless and the array is not mutated after publication.
backport
This needs to be backported to 25.0.