There are numerous circumstances in which the VM allocates memory but could avoid doing so. When the allocation volume is high enough it pays off to avoid the allocation, initialization, and destruction of those objects. This tracker is for work items that implement optimizations in the VM (not in ASC) that removes allocations that are semantically necessary but where the avoidance of allocation is not detectable. Examples are: - ...rest arguments that don't escape - 'arguments' objects that don't escape - function closures that don't escape (local function definitions rarely do, for example)
We could optimize allocation of catch activation objects (OP_newcatch), but intuition says its not worth the effort if we assume catch blocks are cold code. However, the analysis is probably not super hard -- catch objects only have one variable, and rarely if ever escape.
If we can favorably specify identity semantics for function closures then we may be able to avoid allocating new function closures (and underlying MethodEnv and ScopeChain objects).
The icky part about optimizing closures is that the language has pointer equality for functions, and the event handler mechanism uses this fact (removeEventHandler uses pointer equality I think). Otherwise it would be extremely appealing to lift function expressions even when their values are used.
(Duh, what Ed said.)
IIRC there's an escape hatch with weird semantics in the ecma spec that an implementation can re-use a closure instance in some circumstances. Might be moot for actionscript compatibility. maybe we table this until the AS language can be tweaked (similar coping to proposed const changes). vm hosts counting on pointer equality of any AS value is evil api leakage, hmm.
(In reply to comment #3) > The icky part about optimizing closures is that the language has pointer > equality for functions, and the event handler mechanism uses this fact > (removeEventHandler uses pointer equality I think). Otherwise it would be > extremely appealing to lift function expressions even when their values are > used. aha! well, even if we must allocate the close Function instance, we maybe can reuse underlying instances of ScopeChain and MethodEnv. those aren't AS visible and probably (cough) aren't touched by VM hosts.
Target Milestone: Q3 11 - Serrano → Q1 12 - Brannan
You need to log in before you can comment on or make changes to this bug.