Open Bug 1858746 Opened 2 years ago Updated 2 years ago

atomize more nursery strings during deduplication

Categories

(Core :: JavaScript Engine, task, P3)

task

Tracking

()

ASSIGNED

People

(Reporter: sfink, Assigned: sfink)

References

(Blocks 1 open bug)

Details

(Whiteboard: [sp3])

Attachments

(1 file)

While writing a test for my stats gathering for bug 1846297, I noticed that my test string that I was using as a lookup key was not getting atomized during deduplication as I expected. I discovered that atomization during deduplication only happens for longer strings (StringToAtomCache::MinStringLength, 39 chars), but that threshold appears to have been chosen because shorter strings are faster to hash and so the cost of an extra cache lookup is less worth it. That logic doesn't apply as much to deduplication.

So I experimented with allowing longer than inline but shorter than StringToAtomCache::MinStringLength strings to be deduplicated. It's more code duplication and change than I'd like, and the number of strings this applies to is surprisingly (to me) small.

Speedometer 3 without the patch:

               ReplaceWithAtom count=      457   0.0% bytes=       31964   0.1%
                   Deduplicate count=   876726  42.8% bytes=     8960350  30.7%
           CopyInlineToTenured count=   729033  35.6% bytes=     7245160  24.8%
             CopyRopeToTenured count=   188288   9.2% bytes=           0   0.0%
        CopyDependentToTenured count=   169384   8.3% bytes=           0   0.0%
         CopyMallocedToTenured count=    83481   4.1% bytes=    12925836  44.3%

With the patch, so that mid-size strings that have been atomized will be atomized during tenuring:

               ReplaceWithAtom count=     3013   0.1% bytes=      106786   0.4%
                   Deduplicate count=   855339  42.2% bytes=     8829713  32.3%
           CopyInlineToTenured count=   744519  36.7% bytes=     7369113  26.9%
             CopyRopeToTenured count=   177470   8.7% bytes=           0   0.0%
        CopyDependentToTenured count=   169135   8.3% bytes=           0   0.0%
         CopyMallocedToTenured count=    79735   3.9% bytes=    11053080  40.4%
Assignee: nobody → sphink
Status: NEW → ASSIGNED

(Note that the byte counts for ropes and dependent strings are zero because I'm only counting the owned chars, since otherwise ropes will count their constituent chars many, many times and the percentages will get washed out by the quadratic overcounting.)

Severity: -- → S3
Priority: -- → P3
Whiteboard: [sp3]

We sort of have a table of different buckets of strings, and it might be useful to change the behavior for some of the buckets. The buckets are defined by their length (so, short inline vs longer inline vs short out of line vs longer out of line, where the exact lengths of the bucket divisions would need to be guessed or tuned.) And also whether the string has ever been looked up as an atom, and/or is currently in the string to atom cache (which is a superset of the former).

I didn't paste it in, but the string stats I pasted above also have a histogram of string lengths for strings that get tenured. Just knowing the length distribution doesn't really say what the best behavior would be, though.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: