e17e46fde6
This refactors the ThreadLocalTop into separate header and implementation files, and moves it from the Isolate to the IsolateData (with some tweaks to make the layout of the class predictable). This has the advantage that all external references referring to addresses in the ThreadLocalTop (like js_entry_sp, c_function, c_entry_fp, etc.) need only a single memory access to reach them. For example the CallApiCallback can now use ``` mov %rbp,0x8e40(%r13) mov %rsi,0x8de0(%r13) mov %rbx,0x8e50(%r13) ``` to setup the information about context, frame pointer, and C++ function pointer in the ThreadLocalTop instead of the previously generated code ``` mov 0x2e28(%r13),%r10 mov %rbp,(%r10) mov 0x2e38(%r13),%r10 mov %rsi,(%r10) mov 0x2e30(%r13),%r10 mov %rbx,(%r10) ``` which always had to load the scratch register %r10 with the actual address first. This has interesting performance impact. On the test case mentioned in v8:8820 (with the `d8` patch applied), the performance goes from ``` console.timeEnd: fnMono, 2290.012000 console.timeEnd: fnCall, 2604.954000 ``` to ``` console.timeEnd: fnMono, 2062.743000 console.timeEnd: fnCall, 2477.556000 ``` which is a pretty solid **10%** improvement for the monomorphic API accessor case, and a **5%** improvement for calling into the API accessor instead. But there might as well be other places besides API callback calls that will benefit from this change, which I haven't tested explicitly. Although this change is supposed to be as minimal as possible without any functional effects, some changes were necessary/logical. Eventually we should reconsider changing the layout and the types for the fields in the ThreadLocalTop to be more consistent with the other IsolateData entities. But this can be done in separate follow-up CLs, as this will be quite a bit of churn on the code base, depending on how we do that exactly, and is orthogonal to this optimization. Bug: v8:8820, v8:8848, chromium:913553 Change-Id: I4732c8e60231f0312eb7767358c48bae0338220d Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Reviewed-on: https://chromium-review.googlesource.com/c/1474230 Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#59624} |
||
---|---|---|
benchmarks | ||
build_overrides | ||
custom_deps | ||
docs | ||
gni | ||
include | ||
infra | ||
samples | ||
src | ||
test | ||
testing | ||
third_party | ||
tools | ||
.clang-format | ||
.clang-tidy | ||
.editorconfig | ||
.git-blame-ignore-revs | ||
.gitattributes | ||
.gitignore | ||
.gn | ||
.vpython | ||
.ycm_extra_conf.py | ||
AUTHORS | ||
BUILD.gn | ||
ChangeLog | ||
CODE_OF_CONDUCT.md | ||
codereview.settings | ||
DEPS | ||
LICENSE | ||
LICENSE.fdlibm | ||
LICENSE.strongtalk | ||
LICENSE.v8 | ||
LICENSE.valgrind | ||
OWNERS | ||
PRESUBMIT.py | ||
README.md | ||
snapshot_toolchain.gni | ||
WATCHLISTS |
V8 JavaScript Engine
V8 is Google's open source JavaScript engine.
V8 implements ECMAScript as specified in ECMA-262.
V8 is written in C++ and is used in Google Chrome, the open source browser from Google.
V8 can run standalone, or can be embedded into any C++ application.
V8 Project page: https://github.com/v8/v8/wiki
Getting the Code
Checkout depot tools, and run
fetch v8
This will checkout V8 into the directory v8
and fetch all of its dependencies.
To stay up to date, run
git pull origin
gclient sync
For fetching all branches, add the following into your remote
configuration in .git/config
:
fetch = +refs/branch-heads/*:refs/remotes/branch-heads/*
fetch = +refs/tags/*:refs/tags/*
Contributing
Please follow the instructions mentioned on the V8 wiki.