1606600 - Consider moving GC hooks out of JSClassOps

Status: NEW

(Core :: JavaScript Engine, task, P2)

Description

[Jan de Mooij [:jandem]]

JSClassOps is often used for classes that need custom GC trace/finalize behavior but don't need to override the other class ops. ClassExtension nowadays only has the objectMovedOp field.

I think it would make sense to replace ClassExtension with a new struct that contains just the GC-related hooks: trace, finalize, objectMovedOp. It would hopefully shrink our binary size a bit + make it easier to audit/change the actual JSClassOps.

Unfortunately many generated DOM bindings have an _addProperty hook so they'd still need a JSClassOps for that. I'd like to get rid of that hook at some point, but that's probably not happening soon. Maybe these bindings could share a single JSClassOps instance, though.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Unfortunately, the _addProperty hook bindings use relies on the concrete class of the object in its current form (and is codegenned as a result), so we couldn't share it without some more work...

Comment 2

[Iain Ireland [:iain]]

I took a more detailed look at JSClassOps, with the goal of reducing the number of instances of JSClass that need a JSClassOps.

There are ~1200 generated DOM classes, and ~90 handwritten instances. Among generated classes:

• 800+ have hooks for exactly addProp and finalize. addProp is used for the wrapper cache.
• ~350 have hooks for exactly call and construct. In all but three cases, the call and construct hooks are the same.
• ~30 have only a finalize hook.
• Only 12 generated classes don't fall into the above categories.
• All DOM classes generate a classExtension, even though many of them don't use it.

Among handwritten classes:

• 60+ only have trace and/or finalize hooks
• In all cases where call and construct hooks both exist, they're the same.

My takeaways:

1. trace and finalize are common enough that we could even consider hoisting them into JSClass itself, to speed up access.
2. If we could find a different way to express addProp for the wrapper cache, then we could eliminate 2/3 of generated JSClassOps. One possibility for doing this might be to a) add a flag on the JSClass to mark DOM classes that participate in the wrapper cache, b) check that flag in the appropriate places inside SM , and c) call a single implementation of addProperty that uses getWrapperCache to cast from the concrete type. The same trick might also work for objectMoved.
3. It doesn't seem like there's a lot of value in having separate call and construct hooks. We could combine them and pass a flag. Hoisting the combined callOrConstruct hook into the JSClass would remove most of the remaining generated JSClassOps.

If we move forward with this, we should try to contain it within a single release cycle to avoid churn for embedders.