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.

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.

(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

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

The merge of ObjShrink regressed a bunch of Talos tests, according to tree-management.

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

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.

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?

I don't think this bug needs to be open any more.