1923903 - Instantiate only one Object Actor/Front pair for all unique JS values when recording JS Traces

Status: RESOLVED FIXED

(DevTools :: Debugger, enhancement)

Description

[Alexandre Poirot [:ochameau]]

For now, the JS Tracer is following the same behavior as the web console actor, as well as all callsites of createValueForTarget.
A new Object Actor is instantiated any time we want to communicate a new JS value to the client via RDP.
That, even if we already notified the client about the same JS value via an existing Object Actor instance.

The thread actor is different and tries to instantiate Object Actor's only once per unique JS Object.
We should try following the same principles in the tracer actor.
It should save some cycles by making the Actor Pools smaller.
But it will also help identify unique JS values from the frontend side and is a blocker for bug 1921020.

Comment 1

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1923903 - [devtools] Use ObjectActorPool to instantiate and collect all Object Actors.

This dedicated pool class shared by all the actors instantiating Object Actors
(console, thread and tracer actors) is going to later help reuse the same
WeakMap logic to instantiate only one actor per unique JS value.

I also merged console and target actor to use the same pool
as they basically have the same lifecycle. This simplify lookups
by Actor IDs done for selected object actor or console table objects.

Comment 2

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1923903 - [devtools] Ensure updating object front's form when re-using the same front instance.

When we communicate a previously notified object actor form,
which was notified through a prevent RDP event or method call,
we passed its actor's form (a.k.a. "grip").
This contains a snapshot of the object in order to be able to display a preview
of it at the time the object was processed in the backend.

Now, when we manipulate the same JS value in the backend,
we may notify about the same object actor instance, but the actor's form ("grip")
will be updated to match the current state of the object.

In the frontend, we need to process this new form/grip in the Object Actor front,
so that the previews are correctly updated over time.

Comment 3

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1923903 - [devtools] Instantiate only one object actor per JS object in the JS Tracer.

Comment 4

[Alexandre Poirot [:ochameau]]

When tweaking DAMP to enable values tracing, I'm able to see a 10% speedup in tracing with this patch queue:
https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=c97a5bc80ca07d69c349dae6274e2b1765037931&originalSignature=4763542&newSignature=4763542&framework=12&application=firefox&originalRevision=d47a821cbcb739c410bf06fa3de863dad07f612e&page=1&showOnlyConfident=1&pageTitle=avoid+instantiating+duplicated+objects+actors+%28with+damp+tweak%29

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/67bf76d6340a
[devtools] Use ObjectActorPool to instantiate and collect all Object Actors. r=devtools-reviewers,bomsy
https://hg.mozilla.org/integration/autoland/rev/7780b4f8afad
[devtools] Ensure updating object front's form when re-using the same front instance. r=devtools-reviewers,bomsy
https://hg.mozilla.org/integration/autoland/rev/80cb6602d3f6
[devtools] Instantiate only one object actor per JS object in the JS Tracer. r=devtools-reviewers,bomsy

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/67bf76d6340a
https://hg.mozilla.org/mozilla-central/rev/7780b4f8afad
https://hg.mozilla.org/mozilla-central/rev/80cb6602d3f6