Closed Bug 631818 Opened 13 years ago Closed 5 months ago

Don't eagerly initialize slots to undefined

Categories

(Core :: JavaScript Engine, defect)

x86
All
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: gal, Unassigned)

Details

Attachments

(1 file)

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.
Attached patch patchSplinter Review
Can GC deal with uninitialized slots nowadays?
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
Severity: normal → S3
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: