Starlight implements them almost like in V8 and Boa for sure will need custom GC for this plus a lot of unsafe code. Custom GC is required because for serialization and deserialization how objects are allocated does matter plus all the GC objects need to implement some trait for deser/ser, in Starlight there is a base trait for all GCed objects: GcCell and GcCell requires impl of Serializable and Deserializable. There is also a large array that contains all the native functions or other data exposed to JS VM: jsrt.rs + additional array stored in VM instance so serializer and deserializer know where to get external references.

Serialization and deserialization impl is there:
https://github.com/Starlight-JS/starlight/tree/dev/crates/starlight/src/gc/snapshot

Yeah we need a new GC, rust-gc makes somethings really awkward, also there is not much control (like changing the threshold, or changing when we want collect).

For me main problem with all the GC crates in Rust is not only the control but how slow and memory inefficient they are. rust-gc if I understand correctly uses reference counting to handle root references which is very slow while other JS engines: V8,JSC and now Starlight just use conservative stack scanning to find roots. There's also alternative like in SpiderMonkey to use shadow stack and Starlight also implements it but its impl is very unsafe and I am not sure if it is possible to implement in safe rust...

Does V8 use conservative stack scanning? I thought it managed roots through scopes (HandleScope) when a scope is destroyed, it's handles are available for collection. since HandleScope keeps track of handles, Handles are copyable.

Matching this in rust would allow us to use lifetimes with scopes and handles, so we could make them more safe.

They did use handles and scopes but now these are just no-op IIRC. They now use the same GC as Blink does: Oilpan GC. It is mostly precise.

https://v8.dev/blog/high-performance-cpp-gc