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

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Andreas Gal :gal]

- 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.

Comment 1

[Brendan Eich [:brendan]]

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

Comment 2

[Ryan VanderMeulen [:RyanVM]]

bhackett says this bug has been fixed by the ObjShrink work.