Don't eagerly initialize slots to undefined




8 years ago
4 years ago


(Reporter: gal, Unassigned)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



8 years ago
We currently set all object slots to undefined when we allocate them. This is really lame and almost always wasteful since we tend to fill those slots with data right away.

The attached patch leaves slots uninitialized until they are actually needed. Arrays are still filled with MagicValue(JS_ARRAY_HOLE). Certain objects want their slots set to undefined (i.e. CallObject), in those places I manually initialize slots.

In debug builds free slots are set to MagicValue(JS_FREE_SLOT) so we can verify that everything is kosher.

This patch saves about 530,000 instructions on SunSpider and doesn't assert in Debug on sunspider. I didn't try anything else yet. xml probably needs a few touch-ups (I know it relies on some reserved slots to be undefined, those have to be set explicitly, this stuff is asserted and easy to catch).

I don't really have the patience to finish this right now (blockers!), but I would love this to go in. I am planning some improvements to typed arrays (inline allocate headers and data instead of 2 JSObjects and 3 mallocs per typed array), for which this patch is crucial.

This is all post-4 work, of course.

Comment 1

8 years ago
Created attachment 510037 [details] [diff] [review]
Can GC deal with uninitialized slots nowadays?

Comment 3

8 years ago
Yes. We check slotSpan. I might have to look closer at deletion but so far it looks good. The patch asserts heavily that everything is ok.
FWIW the packed arrays in the type inference branch do something like this for dense arrays, adding an initializedLength above which slots are uninitialized.
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.