[Webkit-unassigned] [Bug 150186] New: Add MacroAssembler::callProbe() for supporting lambda JIT probes.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=150186

            Bug ID: 150186
           Summary: Add MacroAssembler::callProbe() for supporting lambda
                    JIT probes.
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Local Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mark.lam at apple.com

With callProbe(), we can now make probes that are lambdas.  For example, we can now conveniently add probes like so: 

    // When you know exactly which register you want to inspect:
    jit.callProbe([] (MacroAssembler::ProbeContext* context) {
        intptr_t value = reinterpret_cast<intptr_t>(context->cpu.eax);
        dataLogF("eax %p\n", context->cpu.eax); // Inspect the register.
        ASSERT(value > 10); // Add test code for debugging.
    });

    // When you want to inspect whichever register the JIT allocated:
    auto reg = op1.gpr();
    jit.callProbe([reg] (MacroAssembler::ProbeContext* context) {
        intptr_t value = reinterpret_cast<intptr_t>(context->gpr(reg));
        dataLogF("reg %s: %ld\n", context->gprName(reg), value);
        ASSERT(value > 10);
    });

callProbe() is only meant to be used for debugging sessions.  It is not appropriate to use it in permanent code (even for debug builds).  This is because:
1. The probe mechanism saves and restores all (and I really mean "all") registers, and is inherently slow.
2. callProbe() currently works by allocating (via new) StdFunctionData structs to keep the callback std::function alive, but never deletes them i.e. it leaks a bit of memory each time the JIT runs it.

These limitations are acceptable for a debugging session (assuming you're not debugging a memory leak), but not for deployment code.  If there's a need, we can plug that leak in another patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151015/b50d6bb1/attachment.html>