Closed Bug 1586452 Opened 5 years ago Closed 5 years ago

[jsdbg2] Trace breakpoints directly

Categories

(Core :: JavaScript Engine, task, P2)

task

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox72 --- fixed

People

(Reporter: jimb, Assigned: jimb)

References

Details

Attachments

(10 files, 2 obsolete files)

623 bytes, patch
Details | Diff | Splinter Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review

The algorithm the garbage collector uses to retain Debuggers due to live breakpoint handlers is more complicated than necessary, and should be replaced with a more direct approach.

In the current code, each time through the iterative weak map marking cycle, we search the JSRuntime for marked global objects, see if they are debuggees, and if so, see if their Debuggers have any breakpoints set in marked JSScripts or WasmInstanceObjects. If so, then we mark the Debugger, which marks its breakpoints.

It would be equivalent and simpler to have tracing a JSScript or WasmInstanceObject trace their breakpoint sites, which then traces breakpoints, which then traces Debuggers.

Assignee: nobody → jimb

The Debugger.prototype.enabled accessor was removed in bug 1564168, but there
are still a few stray references to 'enabled' or 'disabled' debuggers in the
docs and the code. These should be cleaned up.

Between breakpoint operations, a BreakpointSite's enabledCount is greater than
zero if and only if its list of breakpoints is empty. Since checking whether the
list is empty is cheap, there's no reason to maintain a separate count.

Depends on D48465

Priority: -- → P2

Yury, I would expect this patch to introduce a bug, because it skips the call to BreakpointSite::recompile for Wasm breakpoints. The test file js/src/jit-test/tests/debug/wasm-breakpoint.js does cover this case, but it seems like the problem gets fixed up by accident someplace else.

Why this patch? I introduced an equivalent bug in the midst of another patch series, and noticed it by eye, and was worried that the tests hadn't caught it. I tried to come up with a test case that would expose the bug, but I haven't been able to.

Can you see any way to come up with a test case that detects the bug this patch introduces?

Flags: needinfo?(ydelendik)
See Also: → 1589906
Attachment #9099435 - Attachment is obsolete: true

That last is a work in progress. Current failures:

    debug/Debugger-onNativeCall-01.js
    debug/Script-clearBreakpoint-01.js
    debug/Script-clearBreakpoint-02.js
    debug/Script-clearBreakpoint-03.js
    debug/Script-getBreakpoints-01.js
    debug/Script-getBreakpoints-02.js
    debug/breakpoint-multi-02.js
    debug/breakpoint-multi-04.js
    debug/wasm-breakpoint.js

Comment on attachment 9099434 [details]
Bug 1586452: Remove stray references to 'enabled' debuggers.

Revision D48465 was moved to bug 1590589. Setting attachment 9099434 [details] to obsolete.

Attachment #9099434 - Attachment is obsolete: true
Attachment #9102822 - Attachment description: Bug 1586452: Use tighter type JSBreakpointSite where possible. → Bug 1586452: Use tighter type JSBreakpointSite where possible. r?jonco
Attachment #9102823 - Attachment description: Bug 1586452: Make BreakpointSite constructor and destructor protected. → Bug 1586452: Make BreakpointSite constructor and destructor protected. r?jonco
Attachment #9102824 - Attachment description: Bug 1586452: Let WasmBreakpointSite hold a WasmInstanceObject*, not a wasm::Instance*. → Bug 1586452: Let WasmBreakpointSite hold a WasmInstanceObject*, not a wasm::Instance*. r?jonco
Attachment #9102825 - Attachment description: Bug 1586452: Remove class js::WasmBreakpoint; use plain js::Breakpoint instead. → Bug 1586452: Remove class js::WasmBreakpoint; use plain js::Breakpoint instead. r?jonco
Attachment #9102826 - Attachment description: Bug 1586452: Make `js::BreakpointSite::remove` the pure virtual method, and hoist `removeIfEmpty' into the base class. → Bug 1586452: Make `js::BreakpointSite::remove` the pure virtual method, and hoist `removeIfEmpty' into the base class. r?jonco
Attachment #9102827 - Attachment description: Bug 1586452: Manage JIT traps when we create and remove breakpoint sites. → Bug 1586452: Manage JIT traps when we create and remove breakpoint sites. r?jonco
Attachment #9102828 - Attachment description: Bug 1586452: SetBreakpointMatcher: success path should be main line. → Bug 1586452: SetBreakpointMatcher: success path should be main line. r?jonco
Attachment #9102829 - Attachment description: Bug 1586452: Separate removal and destruction of Breakpoints into two methods. → Bug 1586452: Separate removal and destruction of Breakpoints into two methods. r?jonco
Attachment #9102830 - Attachment description: Bug 1586452: Trace breakpoints directly. → Bug 1586452: Let JSScripts and wasm::Instances own their BreakpointSites and Breakpoints. r?jonco

Looks green! I'm astonished.

Pushed by jblandy@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1acb660e5fc4
Use tighter type JSBreakpointSite where possible. r=jonco
https://hg.mozilla.org/integration/autoland/rev/0a1e6f5aa6c3
Make BreakpointSite constructor and destructor protected. r=jonco
https://hg.mozilla.org/integration/autoland/rev/d0d79b88fd49
Let WasmBreakpointSite hold a WasmInstanceObject*, not a wasm::Instance*. r=jonco
https://hg.mozilla.org/integration/autoland/rev/4d3fe0b93397
Remove class js::WasmBreakpoint; use plain js::Breakpoint instead. r=jonco
https://hg.mozilla.org/integration/autoland/rev/7fc4169017bc
Make `js::BreakpointSite::remove` the pure virtual method, and hoist `removeIfEmpty' into the base class. r=jonco
https://hg.mozilla.org/integration/autoland/rev/b49320ce9db5
Manage JIT traps when we create and remove breakpoint sites. r=jonco
https://hg.mozilla.org/integration/autoland/rev/df4696b00c37
SetBreakpointMatcher: success path should be main line. r=jonco
https://hg.mozilla.org/integration/autoland/rev/dca8e34d8b27
Separate removal and destruction of Breakpoints into two methods. r=jonco
https://hg.mozilla.org/integration/autoland/rev/843d64235cfa
Let JSScripts and wasm::Instances own their BreakpointSites and Breakpoints. r=jonco
Regressions: 1591080
See Also: → 1594255
Flags: needinfo?(ydelendik)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: