Comment #3 on issue 1808 by [email protected]: String concatenation to a
length of two is slow possibly due to table lookup
http://code.google.com/p/v8/issues/detail?id=1808
r9871 exposed a bug on mips, our engineers Duane Sand and Daniel Kalmar
investigated. They found problems in arm arch, and a possible problem in
all arches, which seem to be related to this issue. Here are the initial
conclusions:
First, the arm version of
StringHelper::GenerateTwoCharacterSymbolTableProbe returns result = scratch
(= scratch3), and it should return result = candidate (= scratch5)
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/arm/code-stubs-arm.cc#5631
Second, all arch are comparing to kNullValueRootIndex, and should be
changed to check kTheHoleValueRootIndex:
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/arm/code-stubs-arm.cc#5601
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/mips/code-stubs-mips.cc#5791
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/ia32/code-stubs-ia32.cc#5802
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/x64/code-stubs-x64.cc#4738
Third, the C code for computing string hashes uses an unsigned accumulator,
which will result in logical right shifts, but the architectures all use
arithmetic right shifts. I suspect this results in bad sym-table probes in
the generated code, requiring a fallback to slow-path, but we have not
validated this assumption.
In 3 locations near the following in each arch:
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/arm/code-stubs-arm.cc#5643
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/mips/code-stubs-mips.cc#5833
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/ia32/code-stubs-ia32.cc#5873
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/x64/code-stubs-x64.cc#4789
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
