GitHub (Dec 18 2019 at 19:40): GitHub (Dec 18 2019 at 19:40):hotsphink commented on Issue #1176:
SpiderMonkey GC (incremental and generational; has both pre-write and post-write barriers; if we include various weak caches, it also has read barriers, but these are used rarely, and are only used in C++ VM code AFAIK)
This isn't entirely true. SpiderMonkey very commonly uses read barriers in the interface with the Gecko embedding, for integrating with the cycle collector. Any embedding object that might be a member of a collectible cycle will have a read barrier that prevents it from being cycle collected.
Specifically,
JS::Heap<T>has a read barrier that doesUnmarkGrayGCThingRecursivelyakaExposeGCThingToActiveJS, though note that "gray" in that name is "CC gray", not at all the same as the "gray" in https://github.com/bytecodealliance/cranelift/issues/1176#issuecomment-566790342. It's not a weak reference, it's more a workaround for not having write barriers throughout the embedding.I don't know if that's at all relevant here, though.
GitHub (Dec 18 2019 at 22:06):sunfishcode commented on Issue #1176:
In support of the plan here, I've now submitted https://github.com/bytecodealliance/cranelift/pull/1299 to start generalizing global values into templates.
GitHub (Dec 19 2019 at 19:55):fitzgen commented on Issue #1176:
First off: thanks for the detailed responses everyone!
@eqrion great! Sounds like we can work in parallel :)
A good incremental stepping stone might be using templates (once we have them working with
store_ref) to simply emit a call to the out of line functions you're implementing now.
@bnjbvr
Since WeakRefs are making their way into JS, I'd expect that we'd have them in wasm too, and they'll probably require the read barrier (later).
@hotsphink
SpiderMonkey very commonly uses read barriers in the interface with the Gecko embedding, for integrating with the cycle collector. Any embedding object that might be a member of a collectible cycle will have a read barrier that prevents it from being cycle collected.
Great points! It probably does make sense to support read barriers from the get-go then.
Out of curiosity, does ion ever emit inline read barriers for objects in its JIT'd code, similar to those used by
JS::Heap<T>, or do those read barriers only exist in C++ code?
@bnjbvr
There would be an alias kind for GC objects, a different alias kind for others, and a safepoint would be a write of the GC object alias kind. If the alias kinds are controlled by the embedder, then it would also address the last item (An embedder might want slightly different write barriers for references that it knows are different kinds of objects).
Yes, this would work perfectly.
store_refSure :)
GitHub (Dec 19 2019 at 20:31):hotsphink commented on Issue #1176:
Out of curiosity, does ion ever emit inline read barriers for objects in its JIT'd code, similar to those used by
JS::Heap<T>, or do those read barriers only exist in C++ code?From my shaky understanding, there are no read barriers in JIT code. I think a plain property read, for example, would not need a read barrier, at least not until the value read makes its way out to the calling C++ Gecko code. SpiderMonkey code won't read barrier "internal" things even in C++ code, it relies on Gecko to read barrier things that get returned from the JS engine.
The JIT does generate code for both pre- and post-write barriers, when it can't prove they aren't needed.
GitHub (Feb 28 2020 at 23:27):alexcrichton transferred Issue #1176:
Most likely global.set/.get or table.set/.get for reference types will be translated into regular memory load and store instructions. Currently, their implementations are missing at codegen side. The https://github.com/CraneStation/cranelift/pull/1073 performs the translation of the wasm, but CL validator fails when ref types and globals/tables operations are present (see e.g. example)
Last updated: Dec 23 2024 at 13:07 UTC