Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(373)

Issue 1153963010: X87: Move hash code from hidden string to a private symbol (Closed)

Created:
5 years, 6 months ago by chunyang.dai
Modified:
5 years, 6 months ago
Reviewers:
Weiliang
CC:
v8-dev, Michael Hablich
Base URL:
https://chromium.googlesource.com/v8/v8.git@master
Target Ref:
refs/pending/heads/master
Project:
v8
Visibility:
Public.

Description

X87: Move hash code from hidden string to a private symbol port eca5b5d7abc0a9028cb9832087fbf2ed59dadf92 (r28622). original commit message: * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols. * In the long run we should do all hidden properties this way and get rid of the hidden magic 0-length string with the zero hash code. The advantages include less complexity and being able to do things from JS in a natural way. * Initially, the performance of weak set regressed, because it's a little harder to do the lookup in C++. Instead of heroics in C++ to make things faster I moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects. * This also changes hash codes of Smis so that they are always Smis. Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new In a similar vein we could give the magic zero hash code to the hash code symbol. Then when we look up the hash code we would sometimes see the table with all the hidden properties. This dual use of the field for either the hash code or the table with all hidden properties and the hash code is rather ugly, and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL. One worry is that the benchmark results above are more monomorphic than real world code, so may be overstating the performance benefits of moving to JS. I think this is part of a general issue we have with handling polymorphic code in JS and any solutions there will benefit this solution, which boils down to regular property access. Any improvement there will lift all boats. BUG= Committed: https://crrev.com/5211fa0c59cfdca5b7e1872d1cbf792e508ea8b9 Cr-Commit-Position: refs/heads/master@{#28716}

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+1 line, -0 lines) Patch
M src/x87/macro-assembler-x87.cc View 1 chunk +1 line, -0 lines 0 comments Download

Messages

Total messages: 7 (2 generated)
chunyang.dai
PTAL
5 years, 6 months ago (2015-06-01 06:14:56 UTC) #2
Weiliang
lgtm
5 years, 6 months ago (2015-06-01 08:22:07 UTC) #4
commit-bot: I haz the power
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1153963010/1
5 years, 6 months ago (2015-06-01 08:22:10 UTC) #5
commit-bot: I haz the power
Committed patchset #1 (id:1)
5 years, 6 months ago (2015-06-01 08:53:13 UTC) #6
commit-bot: I haz the power
5 years, 6 months ago (2015-06-01 08:53:35 UTC) #7
Message was sent while issue was closed.
Patchset 1 (id:??) landed as
https://crrev.com/5211fa0c59cfdca5b7e1872d1cbf792e508ea8b9
Cr-Commit-Position: refs/heads/master@{#28716}

Powered by Google App Engine
This is Rietveld 408576698