Allocation avoidance optimizations in the VM

NEW
Unassigned

Status

Tamarin
Virtual Machine
P3
normal
8 years ago
7 years ago

People

(Reporter: Lars T Hansen, Unassigned)

Tracking

(Depends on: 3 bugs, Blocks: 1 bug)

unspecified
Q1 12 - Brannan
Dependency tree / graph
Bug Flags:
flashplayer-qrb +
flashplayer-bug -

Details

(Whiteboard: PACMAN, Tracking)

(Reporter)

Description

8 years ago
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)

Updated

8 years ago
Depends on: 570955

Comment 1

8 years ago
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.

Comment 2

8 years ago
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).
(Reporter)

Comment 3

8 years ago
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.
(Reporter)

Comment 4

8 years ago
(Duh, what Ed said.)

Comment 5

8 years ago
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.

Comment 6

8 years ago
(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.
(Reporter)

Updated

8 years ago
Depends on: 477139
(Reporter)

Updated

8 years ago
Depends on: 571468
(Reporter)

Updated

8 years ago
Depends on: 571469
(Reporter)

Updated

8 years ago
Depends on: 571475

Updated

7 years ago
Flags: flashplayer-bug-

Updated

7 years ago
Blocks: 645018

Updated

7 years ago
Flags: flashplayer-qrb+
Target Milestone: Q3 11 - Serrano → Q1 12 - Brannan
You need to log in before you can comment on or make changes to this bug.