The default bug view has changed. See this FAQ.

TM: JM: NewObject is way to fat and branchy [meta]

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: gal, Assigned: Paul Biggar)

Tracking

Other Branch
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
- Slots are always initialized, even though the call site usually overwrites them right away. We should teach the GC to not scan uninitialized slots.
- We check in JSObject::init whether to allocate dslots. All this code is very branchy and wasteful.
- We initialize the private slot conditionally with NULL or VOID. Expensive branch, and frequently mis-predicted to boot.
- The proto/parent lookup looks expensive. I wonder whether we can do something more clever here.
(Reporter)

Updated

7 years ago
Summary: TM: NewObject is way to fat and branchy → TM: JM: NewObject is way to fat and branchy [meta]
(Reporter)

Updated

7 years ago
Depends on: 566076
(Reporter)

Updated

7 years ago
No longer depends on: 566076
(Reporter)

Updated

7 years ago
Depends on: 566076, 578156
(Reporter)

Updated

7 years ago
Depends on: 578158
(Reporter)

Updated

7 years ago
Depends on: 578159
(Reporter)

Updated

7 years ago
Assignee: general → paul.biggar
In the interest of not conflicting, and more important: not duplicating effort, please have a look at the patch for bug 558451. I've got a huge queue there. An early patch in the queue inflates JSObject to be twice as large as tm tip, which has unlandable perf and memory consequences. Other than that, feel free to pull code out of there.

I'll attach a fresh hg export of my queue later today.

/be
bhackett says this bug has been fixed by the ObjShrink work.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.