Make wrappers non-native, using proxies [meta]

NEW
Unassigned

Status

()

Core
JavaScript Engine
8 years ago
4 years ago

People

(Reporter: gal, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
We probably want to split this in a couple sub-bugs for each wrapper.

Advantages:
- for a simple wrapper (SOW) this traces 10 lines for hundreds of lines of existing code
- non-native wrappers are faster to operate on, no need to locally "shadow" each operation and update the property tree
- non-native wrappers use less memory since we don't cache properties locally
- we can make expandos survive explicitly where needed, but only when we have expandos do we need storage for them
- be more transparent and less leaky
- if we start tracing proxies, we will automatically also optimize wrappers
(Reporter)

Updated

8 years ago
Depends on: 546590
OS: Mac OS X → All
Hardware: x86 → All
(Reporter)

Comment 1

8 years ago
Not to mention, this also eliminates a whole bunch of open bugs we have for wrappers that result from their non-nativeness, i.e. keys() only shows properties that have been resolved so far.

Updated

8 years ago
Depends on: 566818

Updated

8 years ago
No longer depends on: 566818
(Assignee)

Updated

4 years ago
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.