631818 - Don't eagerly initialize slots to undefined

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Andreas Gal :gal]

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

[Andreas Gal :gal]

Attachment: patch

Comment 2

[Boris Zbarsky [:bzbarsky]]

Can GC deal with uninitialized slots nowadays?

Comment 3

[Andreas Gal :gal]

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.

Comment 4

[Brian Hackett [Laid off!]]

FWIW the packed arrays in the type inference branch do something like this for dense arrays, adding an initializedLength above which slots are uninitialized.