Last Comment Bug 571726 - TM: JM: NewObject is way to fat and branchy [meta]
: TM: JM: NewObject is way to fat and branchy [meta]
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Other Branch
: x86 Mac OS X
-- normal with 1 vote (vote)
: ---
Assigned To: Paul Biggar
: Jason Orendorff [:jorendorff]
Depends on: 566076 578156 578158 578159
  Show dependency treegraph
Reported: 2010-06-12 19:41 PDT by Andreas Gal :gal
Modified: 2011-11-16 16:40 PST (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Andreas Gal :gal 2010-06-12 19:41:52 PDT
- 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 User image Brendan Eich [:brendan] 2010-07-12 14:02:35 PDT
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.

Comment 2 User image Ryan VanderMeulen [:RyanVM] 2011-11-16 16:40:39 PST
bhackett says this bug has been fixed by the ObjShrink work.

Note You need to log in before you can comment on or make changes to this bug.