Summary

Fixes a ThreadSanitizer-detected data race when accessing Function::unoptimized_code between the main compilation thread and background optimizer thread.

Issue

Fixes #61800

ThreadSanitizer detected a data race where:

• Main thread writes to unoptimized_code via Function::set_unoptimized_code() during compilation
• Background compiler thread reads unoptimized_code during the inlining optimization pass in CallSiteInliner::GetParsedFunction()

This unsynchronized access could lead to:

• Reading stale or partially-written pointer values
• Undefined behavior on ARM architectures with weak memory ordering
• Potential crashes or incorrect optimization decisions

Changes

Applied proper acquire-release synchronization to Function::unoptimized_code accessors:

runtime/vm/object.h:

• Modified unoptimized_code() getter to use std::memory_order_acquire when reading

runtime/vm/object.cc:

• Modified set_unoptimized_code() setter to use std::memory_order_release when writing

The existing COMPRESSED_POINTER_FIELD macro already supports templated memory ordering, so this change leverages that existing infrastructure.

Memory Ordering Semantics

• Release semantics on write: Ensures all prior memory operations are visible before the store
• Acquire semantics on read: Ensures all memory operations from the releasing thread are visible after the load
• This establishes a "happens-before" relationship that eliminates the race condition

Related Work

This follows the same pattern used for other concurrent code access in the Dart VM and is consistent with the existing memory ordering support in the COMPRESSED_POINTER_FIELD macro infrastructure.

TEST=language/vm/regression_39193_test

• [ x] I’ve reviewed the contributor guide and applied the relevant portions to this PR.