New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: JSManaged vs. JSTraceable objects #32102
Comments
Questions:
|
Are "JS managed" objects a strict superset of objects that implement |
That it needs to be GCed.
So we do not have to write
That's alternative solution.
that's just for illustration purposes, in reality both would have same signature and same name.
I completely forgot that existed. Will add it. |
Another alternative is something like this: This code could be generated in proc-macro of JSTraceable, so |
So do I understand this correctly that a "JS managed" object is one that needs to be garbage collected, but a |
JS managed is object that needs to be GCed (either fully or only one of it's fields). JSTraceable is trait that traces all JSManaged types to detect usages between them. Because we know rust primitives are not JSManaged they get nop implementation for their tracer. Dom objects are js managed, but can have fields that are not js managed, those fields implement nop tracers (or have In general each type that has non-trivial tracer implementation is jsmanaged (usually such struct a field of type EDIT: We also have some doc in tree: https://github.com/servo/servo/blob/main/components/script/docs/JS-Servos-only-GC.md |
Hrm. So these traits are essentially: |
Well JSManaged types are for both, while JSTraceable are just types that implements JSTraceable even if they are not GCed. |
Generally all objects that implements
JSTraceable
should be js managed, but some types have nopJSTraceable
impl (are not js managed).But for
no_trace
and for #26488 having more strict definition would help achieve correctness.Option A: Create
JSManaged
(marker) trait as subtrait ofJSTraceable
Problems:
How to guarantee that all types that are js managed (have non-trivial JSTraceable) are actually marked as such? More Crown Lints!
Option B: "disallow"/remove nop JSTraceable
Disallow nop JSTraceable so all objects that implement traceable are actually js managed. What would enforce such rule? Nothing, but if any type would get nop JSTraceable this could only result false errors triggered by lints.
Problem:
We would need to use a lot more
no_trace
(~600 errors are generated when removing nop implementations from mozjs).Option C: Make JSTraceable only for jsmanaged
This option is similar to option B but it goes in opposite direction as no_trace. Using some typesystem trickery we can do something like this:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9fa68d01e0dc08f3e24997fd3b31d46d, to dispatch in compile-time which tracer would be run (code would be generated in proc-macro of JSTraceable). If
JSTraceable
is implemented for type then tracer from trait would be called in other case type does not implementJSTraceable
so nop traceable would be called.Good news is that this would remove the need for no_trace and manual nop tracers impl, but we would not get errors when struct field is missing JSTraceable as "fallback" (NotJSManaged) tracer would always be available. This could be solved using new lint in crown (if struct/enum has JSTraceable field in inside it should implement JSTraceable via derive).
Problem:
Composed types that has one jsmanaged and one not jsmanaged value ex:
HashMap<i32, JSmanaged>
. This type would also need to be JSTraceable, but it would not be due to bounds requiring both K and V to be JSTraceable (i32 is not). The solution isTrace
wrapper that would wrap non-jsmanaged (assured via lints) type and implement nop traceable on it (polar opposite ofNoTrace
that we have now).The text was updated successfully, but these errors were encountered: