kriskowal: I tried to DM you the link I mentioned, but there are two matrix identities for you in the delegates chat and I may have sent them to the wrong one. Here's what I sent, in any case:

For reference, this Gist contains a brief analysis of an earlier proposed handshaking mechanism: https://gist.github.com/rbuckton/08d020fc80da308ad3a1991384d4ff62
Alternatively, this other gist details possible mechanisms to grant/deny correlation as well as to support bundlers when correlating by source location: https://gist.github.com/rbuckton/b00ca9660fb888486da07b22e38dd1e9

i’m assuming you mean sharing the backing memory, since the objects are necessarily in different realms

oh, right, we’re talking about a new primitive.

there’s no per-worker object that points to the local prototype and shared data

There are many parts of this proposal that make big changes; I'm not convinced that new callables would be worse than some of the other proposed changes

What do you mean by identity discontinuity?

It it imagined that every get/set of an individual property on a shared struct is implicitly an atomic on that individual field?

shared memory parallelism

No, just clarification, I’m wondering whether this proposal implies other web changes like distinguished Worker constructor signatures.

alright, so there isn’t a web API for a process boundary.

By a glance, it looks like this design direction hasn’t been considered or was dismissed out-of-hand:

struct Foo {}
addEventListener('message', event => {
  const foo = new Foo(event.data.foo);
});

Wherein, Foo is an opaque struct definition closing over the vm-specific vagaries of padding, alignment, embedding, dereferencing, &c, event.data.foo is an opaque handle on shared memory without behavior, and new Foo(event.data.foo) unites the data and behavior.

sub-realm prototypes is probably also fine, so long as that inequality roughly holds

I gather from the requirements, that it’s imagined that incrementally replacing a class with a shared struct is a delicate-but-possible performance improving refactor that doesn’t require changes from the consuming code

I really like the design direction where you start with data and work your way out to thread-safe shared behavior too.

Without making the claim that this is actually taking place: in the abstract, I think it would be unfortunate if we locked in a suboptimal design for shared behaviour out of an urge to have something that we can ship sooner. Specifically: if we think we could eventually work out a design for thread-safe shared behaviour, and it would be more performant than the current thread-local prototype approach, then it would be better not to lock ourselves into a local maximum.

i think it's the right choice to have something that can ship in fewer years than a decade...?

The ability to avoid shared prototypes and thread-local hashtables seems like a win

ESM enters the chat

now you also know what i think about ESMs, at least natively

We can't avoid thread-local hashtables if we want to put shared structs in weak maps, which we would need to do if we need to create proxies to emulate the ability to attach behavior. That doesn't go away.

Shared structs in weakmaps effectively requires full stop-the-world cross-worker GC. If you want to include that in the MVP, you are adding an extra K to the N years.

And yeah, there will be some cases where that is difficult and there will be pressure on us to do something better

What are the cases in which you have to be putting these in a map?

I think that there are significant webcompat concerns in cases where engines systematically disagree on whether particular operations leak