Last Comment Bug 637931 - (ObjectShrink) [tracking] JSObject evisceration
(ObjectShrink)
: [tracking] JSObject evisceration
Status: RESOLVED FIXED
[MemShrink:P1][meta]
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
: -- normal with 10 votes (vote)
: ---
Assigned To: Brian Hackett (:bhackett)
:
Mentors:
: 622706 (view as bug list)
Depends on: 650187 637933 638316 641047 684410 684505 684507 687788 690133 693221 693479 694561 697537 699446 707515 707842 709160 710492
Blocks: 650063 mslim-fx5+
  Show dependency treegraph
 
Reported: 2011-03-01 16:15 PST by Bill McCloskey (:billm)
Modified: 2012-01-14 00:23 PST (History)
41 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Bill McCloskey (:billm) 2011-03-01 16:15:58 PST
The goal is to make JSObject as small as possible. In V8, an object is basically a map pointer followed by the slots. Here's what we have right now:

- shape
- clasp
- flags (32-bit)
- object shape (32-bit)
- emptyShapes (pointer to array, usually NULL)
- proto
- parent
- privateData
- capacity
- slots

V8 stores much of this information in the Map. It's not clear how difficult this would be for us to do. We should file separate bugs for each member and track them with this bug.
Comment 1 Andreas Gal :gal 2011-03-01 16:22:06 PST
As part of the cycle collector improvements I want to remove parent from all non-functions (the parent link to a global is a frequent participant in cycles and leaks). This is something we can do for FF5. If I can have someone from JS to work on this that would be awesome.
Comment 2 Brendan Eich [:brendan] 2011-03-01 17:40:18 PST
(In reply to comment #0)
> The goal is to make JSObject as small as possible. In V8, an object is
> basically a map pointer followed by the slots. Here's what we have right now:
> 
> - shape
> - clasp
> - flags (32-bit)
> - object shape (32-bit)
> - emptyShapes (pointer to array, usually NULL)
> - proto
> - parent
> - privateData
> - capacity
> - slots

We also have one big wide type, JSObject, with a JSFunction subtype. IIRC v8 has lots of subclasses, some adding more data members -- true?

> V8 stores much of this information in the Map. It's not clear how difficult
> this would be for us to do. We should file separate bugs for each member and
> track them with this bug.

We need to understand the trade-offs better, or we could just be eating smoke from V8's tailpipe, to put it crudely. We aren't using Ungar-style property maps, unless objects go to dictionary-mode, for example.

/be
Comment 3 Tom Schuster [:evilpie] 2011-03-06 03:51:34 PST
>We also have one big wide type, JSObject, with a JSFunction subtype. IIRC v8
>has lots of subclasses, some adding more data members -- true?

They only add the slots they need. It's a tree like structure, at the top they have HeapObjects. 

eg. 
- HeapObject [map]
 - JSObject [elements] [properties]
    - JSArray [length]
    - JSFunction [context] [code] etc.
    - JSValue (wrapper for primitives, like string, number, date etc) [object]

In v8 every? allocated object/data seems to be a subclass of HeapObject.

Aside i wanted to point out, that TI has a bit different JSObjects.
Comment 4 Nicholas Nethercote [:njn] 2011-06-29 00:03:54 PDT
*** Bug 622706 has been marked as a duplicate of this bug. ***
Comment 5 Andrew McCreight [:mccr8] 2011-12-04 06:27:07 PST
The merge of ObjShrink regressed a bunch of Talos tests, according to tree-management.
Comment 6 Brian Hackett (:bhackett) 2011-12-04 07:18:30 PST
(In reply to Andrew McCreight [:mccr8] from comment #5)
> The merge of ObjShrink regressed a bunch of Talos tests, according to
> tree-management.

The Dromaeo DOM and CSS tests regressed a few %, which was expected (and OK'ed).  The other Dromaeo tests should have stayed flat or improved, though, and V8 should have improved significantly rather than regressing (this from testing the actual browser, not Talos numbers), so something is screwed up.  I'll look into that today.
Comment 7 Brian Hackett (:bhackett) 2011-12-04 09:06:15 PST
I just did several comparisons between v8bench on a recent trunk build with a JM tip build (both x86, same .mozconfig, no other tabs open), and get improvements between 5-9% (somewhat noisy).  e.g.

trunk:

Score: 5405
Richards: 7011
DeltaBlue: 8933
Crypto: 12999
RayTrace: 3294
EarleyBoyer: 6583
RegExp: 1229
Splay: 6212

JM:

Score: 5807
Richards: 8010
DeltaBlue: 9587
Crypto: 13470
RayTrace: 2846
EarleyBoyer: 6687
RegExp: 1247
Splay: 9078

It would be great if someone could do a similar comparison.
Comment 8 Nicholas Nethercote [:njn] 2011-12-06 19:10:58 PST
Now that objshrink has landed on m-c, it seems like a lot of the bugs blocking this bug can be closed, is that right?
Comment 9 Nicholas Nethercote [:njn] 2012-01-10 21:26:32 PST
I don't think this bug needs to be open any more.

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