491170 - statically allocate unit strings and their data

Status: RESOLVED DUPLICATE of bug 513530

(Core :: JavaScript Engine, defect)

Description

[Mike Shaver (:shaver emeritus)]

Attachment: statically allocate unit strings

We should be able to use statically allocated JSString and jschar data for unit strings < UNIT_STRING_LIMIT.  In addition to saving some slight locking and indirection overhead, it would have the bigger advantage of letting us inline str[i] as basically

if (i < str.length)
  if (str.chars[i] > UNIT_STRING_LIMIT)
    ret = call(js_GetDependentString(cx, str.chars[i], i, 1))
  else
    ret = js_UnitStrings + str.chars[i]

and avoid call overhead in the common case (put first in the branch because we want the call path to get compensation code emitted, not be seen first by the register allocator and propagate its spill-pain up to the common path).

Attachment for a first pass at the foundation here, before I fall asleep and then get distracted by the rest of my job.

Comment 1

[Andreas Gal :gal]

What locking overhead? I have not seen the existing code but I assume we optimistically check for unitstring[x] != NULL and then only lock when its NULL and we try to write it. A quick NULL check in the fast path seems a reasonable trade-off to avoid the memory hit from statically allocating the unit strings.

Comment 2

[Brendan Eich [:brendan]]

Comment 1 is right, there is no locking overhead on the fast path.

/be

Comment 3

[Brendan Eich [:brendan]]

Statically allocating the unit strings costs all of 3K on 32-bit targets. We should do it to cut down on codesize and runtime spent on per-runtime constant (totally constant) data. Gregor is gonna fold this bug's patch into the patch for bug 513530.

/be

Comment 4

[Brendan Eich [:brendan]]

Dup'ing forward. Thanks to shaver for prescient bug and wildman patch which was carried forward!

/be