Add shared native memory proposal #4515

mraleph · 2025-09-12T20:49:53Z

This extracts relevant parts of the bigger proposal into a separate proposal.

The following things have changed:

We now include formal memory model: our formalization pretty much follows JavaScripts with some minor tweaks.
All atomic operations are consolidates in a single AtomicInt class - which can be constructed as a view on Pointers or TypedData objects. This is a departure from the previous "zoo of extension methods" design. We should discuss if it is actually better.
I introduced ScopedThreadLocal class which should address some known problematic usages of static state in core libraries.
There are few design points (marked with TODO in the text) which I don't have concrete answers to. We should discuss these.

@lrhn @mkustermann @aam can you take a look?

@aam could you give me the current state of core-library APIs (which already work from IG bound code, which you are fixing and which we will not support). I want to align on what we think is MVP here and include this into the proposal.

mraleph · 2025-09-15T18:19:24Z

cc @leafpetersen

working/333 - shared memory multithreading/shared_native_memory.md

aam · 2025-09-16T03:25:23Z

working/333 - shared memory multithreading/shared_native_memory.md

+```dart
+@pragma('vm:deeply-immutable')
+final class ScopedThreadLocal<T> {
+  /// Creates scoped thread local value with the given [initializer] function.


Nice, but outside of isolate-group-bound callbacks, in the context of standard isolates, does ScopedThreadLocal instance behave like a static field? Isolates in the end can migrate from one thread to another.

Note that isolates can't move between threads in synchronous calls and this API is fully synchronous.

Will there be something that would prevent this infrastructure from being used in asynchronous context?

static Future<String> iterableToShortString(...) { return toStringVisiting.use((toStringVisitingValue) async { await Future.delayed(Duration(seconds: 10)); ...

You can use it. But it is not going to do anything useful because the value of the scoped thread local will reset once the synchronous execution completes.

So toStringVisiting can become unbound after await Future.delayed(Duration(seconds: 10)) (in unlikely event) of isolate switching to a different thread? Realistically we are keeping isolate/(vm)thread affinity, so switching should not happen.

It is not related to moving between threads at all. ScopedThreadLocal are valid within the scope of synchronous execution (hence the name). So if you do stl.use(f) or stl.with(value, f) once synchronous execution of this expression completes stl (e.g. use or with completes) is unbound.

I was curious about the case when f is asynchronous. Would that result in ScopedThreadLocal values bound only for initial synchronous part of f execution? In the example above - before await Future.delayed(Duration(seconds: 10));?

working/333 - shared memory multithreading/shared_native_memory.md

Document constructors memory model

mraleph · 2025-09-17T19:34:05Z

cc @alexmarkov for memory model feedback

working/333 - shared memory multithreading/shared_native_memory.md

lrhn · 2025-09-23T06:02:39Z

working/333 - shared memory multithreading/shared_native_memory.md

+```
+
+Note that `runSync` can only enter an `Isolate` when it is not used by
+another thread.


How will the caller be able to know that?

The other isolate must be back at the event loop, and probably not just the microtask loop.
I guess the isolate can set a flag when its event loop is empty and it's waiting for new events.

You could potentially have a way to check that flag, but that won't guarantee that the isolate didn't get and started processing an event immediately after you checked.

lrhn · 2025-09-23T06:07:07Z

working/333 - shared memory multithreading/shared_native_memory.md

+you invoke this function `f` will be executed in the context of the given
+isolate and then if it produced a `Future` we exit the isolate and block
+the current thread, while allowing the event loop for that isolate to run
+normally until returned future produces result.


That can be implemented using a synchronous/blocking receive port.

It's possible that there is a use for this, but it's rarely a good idea to block your own isolate.

lrhn · 2025-09-23T06:12:16Z

working/333 - shared memory multithreading/shared_native_memory.md

+  external void withInitialized<R>(R Function(T) f);
+
+	/// Returns the value specified by the closest enclosing invocation of [with] or
+	/// throws [NotBoundError] if this [ScopedThreadLocal] is not bound to a value. 


Can just use StateError.

lrhn · 2025-09-23T06:18:22Z

working/333 - shared memory multithreading/shared_native_memory.md

+  /// Throws [NotBoundError] if this [ScopedThreadLocal] does not have an initializer.
+  external void withInitialized<R>(R Function(T) f);
+
+	/// Returns the value specified by the closest enclosing invocation of [with] or


I expect I'll use the pattern:

String toString() { if (!_toStringVisiting.isBound) { return _toStringVisiting.runWith([], (_) => toString()); } var visiting = _toStringVisiting.value; //... }

in every function that depends on the value.

It can't all be abstracted into a helper method like it's it's today, the initialization must be on the main trunk of the execution tree.

Can't you use withInitialized instead?

Given

@pragma('vm:shared') final toStringVisiting = ScopedThreadLocal<List<Object>>(() => <Object>[]);

you can write

String toString() { return toStringVisiting.withInitialized((toStringVisitingValue) {...}) }

which will only invoke initializer if (isolate-group) toStringVisiting instance of ScopedThreadLocal is not bound on this thread yet.

I don't want to double the number of stack frames and generate extra closures if I can avoid it.
I don't expect the call to be a tail-call.

lrhn · 2025-09-23T06:20:27Z

working/333 - shared memory multithreading/shared_native_memory.md

+
+  /// Execute [f] initializing this [ScopedThreadLocal] using default initializer if needed.
+  /// Throws [NotBoundError] if this [ScopedThreadLocal] does not have an initializer.
+  external void withInitialized<R>(R Function(T) f);


I think with may be a reserved word. I think runWith would be the traditional name.

lrhn · 2025-09-23T06:42:58Z

working/333 - shared memory multithreading/shared_native_memory.md

+}
+```
+
+### Synchronization Primitives


What are use-cases?

Communicating between isolates?

lrhn · 2025-09-23T06:46:48Z

working/333 - shared memory multithreading/shared_native_memory.md

+SameLoc_{ww}(w, w') &\triangleq Loc_w(w) = Loc_w(w') \\
+Write(e) & \triangleq Loc_w(e) \neq \emptyset \\
+Unordered(e) & \triangleq \neg(\mathtt{Atomic(e)} \vee \mathtt{Init}(e))
+\end{align*}


Can't review this, because I can't read how it looks. 😔
OK, I copied it into a markdown renderer.

Now I don't know what "≜" means. Is this defining functions or relations?
Says "functions and predicates", so probably functions (some to Bool).

The point of markdown is that the source is readable. LaTeX math isn't, so it feels like it's missing the point.

I was going to suggest using Unicode instead, but &vee; isn't much better then \vee.

Consider just using ASCII and words:

LocR(r) := [Addr(r), Addr(r), + |DataR(r)|]

LocW(r) := [Addr(r), Addr(r), + |DataW(r)|]

Loc(e) := Union(LocR(e), LocW(e))

Overlap(e) := Intersection(LocR(e), LocW(e))

SameLocWR(w, r) := LocW(w) = LocR(r)

SameLocWW(w, w’) := LocW(w) = LocW(w’)

Write(e) := LocW(e) is not empty

Unordered(e) := not Atomic(e) and not Init(e)

lrhn · 2025-09-25T16:08:30Z

working/333 - shared memory multithreading/shared_native_memory.md

+When object is constructed all field initializers (i.e. those provided in the
+body of the class or in the initializer list) result in $\mathtt{Init}$
+write events. The same applies to initialization of individual elements of
+`TypedData` objects with `0`.


And platform lists? (Probably want all object creation to act like initialization, also for collection literals.)

lrhn · 2025-09-25T16:13:08Z

working/333 - shared memory multithreading/shared_native_memory.md

+
+#### Isolates
+
+Every `SendPort.send` generates a numbered event $\mathtt{Send}(p, i)$.


Is the number arbitrary or monotonically increasing?
(The "numbered" makes it sound like the numbers are 1, 2, ..., but it doesn't actually say that.)

lrhn · 2025-09-25T16:13:11Z

working/333 - shared memory multithreading/shared_native_memory.md

+
+$$
+\forall p\,i . \mathtt{Send}(p, i) \leq_\mathtt{asw}\mathtt{Recv}(p, i)
+$$


Do we also want:

∀ p, i, j, Send(p, i) ≤_asw Send(p, j) ↠ Recv(p, i) ≤_asw Recv(p, j)

? That is, sends on the same port are not reordered, but that's proably only true if the sends are in the same isolate.

Add shared native memory proposal

01f6c4e

aam reviewed Sep 16, 2025

View reviewed changes

working/333 - shared memory multithreading/shared_native_memory.md Outdated Show resolved Hide resolved

aam reviewed Sep 16, 2025

View reviewed changes

working/333 - shared memory multithreading/shared_native_memory.md Outdated Show resolved Hide resolved

aam reviewed Sep 16, 2025

View reviewed changes

Few adjustments

c9d5691

aam reviewed Sep 16, 2025

View reviewed changes

working/333 - shared memory multithreading/shared_native_memory.md Show resolved Hide resolved

Document core library API behaviors

3036c75

Document constructors memory model

aam reviewed Sep 24, 2025

View reviewed changes

working/333 - shared memory multithreading/shared_native_memory.md Show resolved Hide resolved

aam reviewed Sep 24, 2025

View reviewed changes

working/333 - shared memory multithreading/shared_native_memory.md Show resolved Hide resolved

lrhn reviewed Sep 25, 2025

View reviewed changes


		#### Isolates

		Every `SendPort.send` generates a numbered event $\mathtt{Send}(p, i)$.

Add shared native memory proposal #4515

Are you sure you want to change the base?

Add shared native memory proposal #4515

Conversation

mraleph commented Sep 12, 2025

Uh oh!

mraleph commented Sep 15, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aam Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mraleph commented Sep 17, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aam Sep 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lrhn Sep 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

aam Sep 16, 2025 •

edited

Loading

aam Sep 26, 2025 •

edited

Loading

lrhn Sep 26, 2025 •

edited

Loading