637931 - (ObjectShrink) [tracking] JSObject evisceration

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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]

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

(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 S [:evilpie]]

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

[Andrew McCreight [:mccr8]]

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

Comment 6

[Brian Hackett [Laid off!]]

(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 [Laid off!]]

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 [inactive]]

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 [inactive]]

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