The Blink GC infrastructure has per-thread heaps - a thread's heap allocations and references will be relative to it. With the allocated objects using Member<> if the reference is to another GCed heap object, or Persistent<> if it is a reference from outside the heap, (strongly) pointing into it and keeping the object alive.
For the (few) times that cross-heap references need to be kept, the CrossThreadPersistent<> abstraction is used. Using Persistent<> for the same is not appropriate.
To detect such Persistent<> use, asserts are in place to verify that a Persistent<> isn't assigned a heap object from another thread's heap. But there are currently no checks in place upon a Persistent<> read -- that it happens only on the owning thread.
Disallowing cross-thread Persistent<> read access has some merit, now and later, hence we should consider adding extra checks to prevent those.
Such read access could indicate that code hasn't fully considered cross-thread use, and the non-barrier'ed cross-heap access is unsafe in the presences of GCs being triggered on the heap owning the object.
Comment 1 by bugdroid1@chromium.org
, Feb 21 2017