On Mon, 22 Jan 2024 20:52:56 GMT, Martin Fox <m...@openjdk.org> wrote:
>> I might be wrong, but array would need to store its size (an int, 8 bytes on >> 64 bit machines) in addition to the pointers themselves, while >> AtomicReference needs just the pointer. >> Plus, its semantics is much cleaner. > > Again, thread-safety isn't an issue here. Even if the OS were to invoke the > IM methods on different threads (which is a terrifying thought) these > adapters are created on a per-call basis so each thread would get its own > instance. This also means those extra eight bytes are transitory. > > If there's an established JavaFX pattern of using AtomicReference instead of > an array I will gladly make the changes. But this does require manual testing > (I still haven't figured out how to automate this) so I'm reluctant to do > this based on personal style preferences. Here is more info [0]. We **are** dealing with multiple threads. I've seen weird cases where modifying memory from different threads without explicit synchronization resulted in subtle bugs - we don't know all the details of cache coherence [1] implementation in multi-core systems, so I would strongly suggest to use AtomicReference. [0] https://stackoverflow.com/questions/70381029/java-atomincinteger-vs-one-element-array-for-streams [1] https://en.wikipedia.org/wiki/Cache_coherence ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1337#discussion_r1462422366
