[Webkit-unassigned] [Bug 16202] New: Optimize allocation of ActivationImp objects

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Nov 30 03:58:15 PST 2007


http://bugs.webkit.org/show_bug.cgi?id=16202

           Summary: Optimize allocation of ActivationImp objects
           Product: WebKit
           Version: 525+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Enhancement
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: cwzwarich at uwaterloo.ca


During the recent flood of optimization of JavaScriptCore, profiling has
revealed that a major issue for performance in the existing interpreter is the
allocation of ActivationImp objects on the JS heap. In particular, this is
likely the cause for JSC's poor performance on control-flow heavy benchmarks in
the SunSpider suite relative to other benchmarks.

Most ActivationImp objects do not need to be allocated in the garbage collected
heap, because they only exist for a static extent. We would like to keep a
WTF::Vector of ActivationImps that we can use as a stack for most purposes. The
question is when we need an ActivationImp to  be torn off and be heap
allocated. For now, I think we need to do it in the following cases:

1) eval

2) with

3) try ... catch

4) local function definitions

5) function expressions

If I am missing anything, please let me know. Some of these may be possible to
eliminate with some form of eval limiting (see bug 15759), but that is a hard
problem, so we can't rely on it being solved for now. We may also be able to
determine a number of these situations statically and mark the node tree so we
don't even allocate on the ActivationImp stack in the first place.

Some issues creep up in the implementation. Every ActivationImp also heap
allocates a private data structure and keeps a pointer to it (to get around the
JSObject size restriction), so we need to also allocate this information on the
stack. My idea was to create a friend class StackActivation that stores both an
ActivationImp and an ActivationImpPrivate object:

We need to be sure we update all the pointers to the ActivationImp or
ActivationImpPrivate when we tear off onto the heap. As far as I can tell, the
only ones that need to be updated are:

1) The pointer from the ActivationImp to the ActivationImpPrivate

2) ExecState::m_activation

3) ExecState::m_variable

4) The top of the scope chain

5) ExecState::m_localStorageBuffer (points into the local storage allocated in
ActivationImpPrivate)

Is this all of them?

I should note that a proper implementation of this optimization is particularly
 important for any future bytecode interpreter, because the gains that come
from not allocating activation frames on the heap will be more pronounced in
that situation.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list