Add links to new locations
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..b66a232
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+x.js
diff --git a/API-stability.md b/API-stability.md
index 2567d44..3a244cb 100644
--- a/API-stability.md
+++ b/API-stability.md
@@ -1,7 +1 @@
-If V8 in a Chromium canary turns out to be crashy, it will get rolled back to the V8 version of the previous canary. It is therefore important to keep V8's API compatible from one canary version to the next.
-
-We continuously run a [bot](https://build.chromium.org/p/chromium.fyi/builders/Linux%20V8%20API%20Stability) that signals API stability violations. It compiles Chromium's HEAD with V8's [current canary version](https://chromium.googlesource.com/v8/v8/+/refs/heads/canary).
-
-Failures of this bot are currently only FYI and no action is required. The blame list can be used to easily identify dependent CLs in case of a rollback.
-
-If you break this bot, be reminded to increase the window between a V8 change and a dependent Chromium change next time.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/api>.
diff --git a/ARM-Debugging.md b/ARM-Debugging.md
index fbb4156..d9e6ca5 100644
--- a/ARM-Debugging.md
+++ b/ARM-Debugging.md
@@ -1,205 +1 @@
-# ARM debugging with the simulator
-
-The simulator and debugger can be very helpful when working with v8 code generation.
-
- * It is convenient as it allows you to test code generation without access to actual hardware.
- * No cross or native compilation is needed.
- * The simulator fully supports the debugging of generated code.
-
-Please note that this simulator is designed for v8 purposes. Only the features used by v8 are implemented, and you might encounter unimplemented features or instructions. In this case, feel free to implement them and submit the code!
-
-
-## Details on the ARM Debugger
-
-Compile the ARM simulator shell with:
-```
-make arm.debug
-```
-on an x86 host using your regular compiler.
-
-### Starting the Debugger
-There are different ways of starting the debugger:
-
-```
-$ out/arm.debug/d8 --stop_sim_at <n>
-```
-The simulator will start the debugger after executing n instructions.
-
-```
-$ out/arm.debug/d8 --stop_at <function name>
-```
-
-The simulator will stop at the given JavaScript function.
-
-Also you can directly generate 'stop' instructions in the ARM code. Stops are generated with
-
-```
-Assembler::stop(const char* msg, Condition cond, int32_t code)
-```
-
-When the Simulator hits a stop, it will print msg and start the debugger.
-
-
-### Debugging commands.
-
-**Usual commands:**
-
-Enter `help` in the debugger prompt to get details on available commands. These include usual gdb-like commands, such as stepi, cont, disasm, etc. If the Simulator is run under gdb, the “gdb” debugger command will give control to gdb. You can then use cont from gdb to go back to the debugger.
-
-
-**Debugger specific commands:**
-
-Here's a list of the ARM debugger specific commands, along with examples.
-The JavaScript file “func.js” used below contains:
-
-```
-function test() {
- print(“In function test.”);
-}
-test();
-```
-
- * **printobject** `<`register`>` (alias po), will describe an object held in a register.
-
-```
-$ out/arm.debug/d8 func.js --stop_at test
-
-Simulator hit stop-at
- 0xb544d6a8 e92d4902 stmdb sp!, {r1, r8, fp, lr}
-sim> print r0
-r0: 0xb547ec15 -1253577707
-sim> printobject r0
-r0:
-0xb547ec15: [Function]
- - map = 0x0xb540ff01
- - initial_map =
- - shared_info = 0xb547eb2d <SharedFunctionInfo>
- - name = #test
- - context = 0xb60083f1 <FixedArray[52]>
- - code = 0xb544d681 <Code>
- #arguments: 0xb545a15d <Proxy> (callback)
- #length: 0xb545a14d <Proxy> (callback)
- #name: 0xb545a155 <Proxy> (callback)
- #prototype: 0xb545a145 <Proxy> (callback)
- #caller: 0xb545a165 <Proxy> (callback)
-```
-
- * **break** `<`address`>`, will insert a breakpoint at the specified address.
-
- * **del**, will delete the current breakpoint.
-
-You can have only one such breakpoint. This is useful if you want to insert a breakpoint at runtime.
-```
-$ out/arm.debug/d8 func.js --stop_at test
-
-Simulator hit stop-at
- 0xb53a1ee8 e92d4902 stmdb sp!, {r1, r8, fp, lr}
-sim> disasm 5
- 0xb53a1ee8 e92d4902 stmdb sp!, {r1, r8, fp, lr}
- 0xb53a1eec e28db008 add fp, sp, #8
- 0xb53a1ef0 e59a200c ldr r2, [r10, #+12]
- 0xb53a1ef4 e28fe004 add lr, pc, #4
- 0xb53a1ef8 e15d0002 cmp sp, r2
-sim> break 0xb53a1ef8
-sim> cont
- 0xb53a1ef8 e15d0002 cmp sp, r2
-sim> disasm 5
- 0xb53a1ef8 e15d0002 cmp sp, r2
- 0xb53a1efc 359ff034 ldrcc pc, [pc, #+52]
- 0xb53a1f00 e5980017 ldr r0, [r8, #+23]
- 0xb53a1f04 e59f1030 ldr r1, [pc, #+48]
- 0xb53a1f08 e52d0004 str r0, [sp, #-4]!
-sim> break 0xb53a1f08
-setting breakpoint failed
-sim> del
-sim> break 0xb53a1f08
-sim> cont
- 0xb53a1f08 e52d0004 str r0, [sp, #-4]!
-sim> del
-sim> cont
-In function test.
-```
-
- * Generated `stop` instuctions, will work as breakpoints with a few additional features.
-
-The first argument is a help message, the second is the condition, and the third is the stop code. If a code is specified, and is less than 256, the stop is said to be “watched”, and can be disabled/enabled; a counter also keeps track of how many times the Simulator hits this code.
-
-If we are working on this v8 C++ code, which is reached when running our JavaScript file.
-
-```
-__ stop("My stop.", al, 123);
-__ mov(r0, r0);
-__ mov(r0, r0);
-__ mov(r0, r0);
-__ mov(r0, r0);
-__ mov(r0, r0);
-__ stop("My second stop.", al, 0x1);
-__ mov(r1, r1);
-__ mov(r1, r1);
-__ mov(r1, r1);
-__ mov(r1, r1);
-__ mov(r1, r1);
-```
-
-Here's a sample debugging session:
-
-We hit the first stop.
-
-```
-Simulator hit My stop.
- 0xb53559e8 e1a00000 mov r0, r0
-```
-
-We can see the following stop using disasm. The address of the message string is inlined in the code after the svc stop instruction.
-
-```
-sim> disasm
- 0xb53559e8 e1a00000 mov r0, r0
- 0xb53559ec e1a00000 mov r0, r0
- 0xb53559f0 e1a00000 mov r0, r0
- 0xb53559f4 e1a00000 mov r0, r0
- 0xb53559f8 e1a00000 mov r0, r0
- 0xb53559fc ef800001 stop 1 - 0x1
- 0xb5355a00 08338a97 stop message: My second stop
- 0xb5355a04 e1a00000 mov r1, r1
- 0xb5355a08 e1a00000 mov r1, r1
- 0xb5355a0c e1a00000 mov r1, r1
-```
-
-Information can be printed for all (watched) stops which were hit at least once.
-
-```
-sim> stop info all
-Stop information:
-stop 123 - 0x7b: Enabled, counter = 1, My stop.
-sim> cont
-Simulator hit My second stop
- 0xb5355a04 e1a00000 mov r1, r1
-sim> stop info all
-Stop information:
-stop 1 - 0x1: Enabled, counter = 1, My second stop
-stop 123 - 0x7b: Enabled, counter = 1, My stop.
-```
-
-Stops can be disabled or enabled. (Only available for watched stops.)
-
-```
-sim> stop disable 1
-sim> cont
-Simulator hit My stop.
- 0xb5356808 e1a00000 mov r0, r0
-sim> cont
-Simulator hit My stop.
- 0xb5356c28 e1a00000 mov r0, r0
-sim> stop info all
-Stop information:
-stop 1 - 0x1: Disabled, counter = 2, My second stop
-stop 123 - 0x7b: Enabled, counter = 3, My stop.
-sim> stop enable 1
-sim> cont
-Simulator hit My second stop
- 0xb5356c44 e1a00000 mov r1, r1
-sim> stop disable all
-sim> con
-In function test.
-```
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/debug-arm>.
diff --git a/Becoming-a-committer.md b/Becoming-a-committer.md
index 00a243b..c17cce1 100644
--- a/Becoming-a-committer.md
+++ b/Becoming-a-committer.md
@@ -1,42 +1 @@
-# What is a committer?
-
-Technically, committers are people who have write access to the V8 Git repository. Committers can submit their own patches or patches from others.
-
-This privilege is granted with some expectation of responsibility: committers are people who care about the V8 project and want to help meet its goals. Committers are not just people who can make changes, but people who have demonstrated their ability to collaborate with the team, get the most knowledgeable people to review code, contribute high-quality code, and follow through to fix issues (in code or tests).
-
-A committer is a contributor to the V8 projects' success and a citizen helping the projects succeed. See [Committer's Responsibility](https://github.com/v8/v8/wiki/Committer's-responsibility).
-
-# How do I become a committer?
-
-In a nutshell, contribute 20 non-trivial patches and get at least three different people to review them (you'll need three people to support you). Then ask someone to nominate you. You're demonstrating your:
-
- * commitment to the project (20 good patches requires a lot of your valuable time),
- * ability to collaborate with the team,
- * understanding of how the team works (policies, processes for testing and code review, etc),
- * understanding of the projects' code base and coding style, and
- * ability to write good code (last but certainly not least)
-
-A current committer nominates you by sending email to v8-committers@googlegroups.com containing:
-
- * your first and last name
- * your Google Code email address
- * an explanation of why you should be a committer,
- * embedded list of links to revisions (about top 10) containing your patches
-
-Two other committers need to second your nomination. If no one objects in 5 working days (U.S.), you're a committer. If anyone objects or wants more information, the committers discuss and usually come to a consensus (within the 5 working days). If issues cannot be resolved, there's a vote among current committers.
-
-Once you get approval from the existing committers, we'll send you instructions for write access to Git. You'll also be added to v8-committers@googlegroups.com.
-
-In the worst case, this can drag out for two weeks. Keep writing patches! Even in the rare cases where a nomination fails, the objection is usually something easy to address like "more patches" or "not enough people are familiar with this person's work."
-
-## Setting up push access to the repository
-
-When you are accepted as a committer make sure to [set up push access to the repo](https://github.com/v8/v8/wiki/Using%20Git#prerequisites).
-
-# Maintaining committer status
-
-You don't really need to do much to maintain committer status: just keep being awesome and helping the V8 project!
-
-In the unhappy event that a committer continues to disregard good citizenship (or actively disrupts the project), we may need to revoke that person's status. The process is the same as for nominating a new committer: someone suggests the revocation with a good reason, two people second the motion, and a vote may be called if consensus cannot be reached. I hope that's simple enough, and that we never have to test it in practice.
-
-(Source: inspired by http://dev.chromium.org/getting-involved/become-a-committer )
+# This content has moved to <https://v8.dev/docs/become-committer>.
diff --git a/Blink-layout-tests.md b/Blink-layout-tests.md
index 804e56e..da751ac 100644
--- a/Blink-layout-tests.md
+++ b/Blink-layout-tests.md
@@ -1,11 +1 @@
-We continuously run [layout tests](https://chromium.googlesource.com/chromium/src/+/master/docs/testing/layout_tests.md) on our [FYI waterfall](https://ci.chromium.org/p/v8/g/fyi/console?branch=master) to prevent integration problems with Chromium.
-
-On test failures, the bots compare the results of V8 Tip-of-Tree with Chromium's pinned V8 version, to only flag newly introduced V8 problems (with false positives <<5%). Blame assignment is trivial as the [Linux release](https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064) bot tests all revisions.
-
-Commits with newly introduced failures are normally reverted to unblock auto-rolling into Chromium. In case you break layout tests and the changes are expected, follow this procedure:
-
- 1. Land a Chromium change setting `[ Failure Pass ]` for the changed tests ([more](https://chromium.googlesource.com/chromium/src/+/master/docs/testing/layout_test_expectations.md#How-to-rebaseline)).
- 1. Land your V8 CL and wait 1-2 days until it cycles into Chromium.
- 1. Switch `[ Failure Pass ]` to `[ NeedsRebaseline ]` in Chromium. Tests will be automatically rebaselined.
-
-Please associate all CLs with a BUG.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/blink-layout-tests>.
diff --git a/Building-from-Source.md b/Building-from-Source.md
index 3cc5027..ed236b9 100644
--- a/Building-from-Source.md
+++ b/Building-from-Source.md
@@ -1,60 +1 @@
-In order to be able to build V8 from scratch on Windows/Linux/Mac for x64 please heed the following steps:
-
-## Getting the V8 source TL;DR
-
-More in-depth information can be found [here](https://github.com/v8/v8/wiki/Checking%20out%20source).
-
-1. On Linux or Mac, first install [git](https://github.com/v8/v8/wiki/Using%20Git#prerequisites) and then [depot_tools](http://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up).
- On Windows, follow the Chromium instructions ([for Googlers](https://goto.google.com/building-chrome-win), [otherwise](https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Setting-up-Windows)) to install Visual Studio, Debugging tools for Windows and depot_tools (which on Windows includes git).
-
-2. Update `depot_tools` by executing the following into your terminal/shell. On Windows, this has to be done in the Command Prompt (cmd.exe), as opposed to PowerShell or others.
-
- ```sh
- gclient
- ```
-
-4. Go into the directory where you want to download the V8 source into and execute the following in your terminal/shell:
-
- ```sh
- fetch v8
- cd v8
- ```
-
-**Don’t simply `git clone` the V8 repository!**
-
-## Building V8 TL;DR
-
-More in-depth information can be found [here](https://github.com/v8/v8/wiki/Building%20with%20GN).
-
-1. For macOS: install Xcode and accept its license agreement. (If you’ve installed the command-line tools separately, [remove them first](https://bugs.chromium.org/p/chromium/issues/detail?id=729990#c1).)
-
-2. Make sure that you are in the V8 source directory. If you followed every step up until step 4 above, you’re already at the right location.
-
-3. Download all the build dependencies by executing the following in your terminal/shell:
-
- ```sh
- gclient sync
- ```
-
-4. (only on linux, only needed once) Install build dependencies by executing the following in your terminal/shell:
-
- ```sh
- ./build/install-build-deps.sh
- ```
-5. Generate the necessary build files by executing the following in your terminal/shell:
-
- ```sh
- tools/dev/v8gen.py x64.release
- ```
-
-6. Compile the source by executing the following in your terminal/shell:
-
- ```sh
- ninja -C out.gn/x64.release
- ```
-
-7. Run the tests by executing the following in your terminal/shell:
-
- ```sh
- tools/run-tests.py --gn
- ```
+# This content has moved to <https://v8.dev/docs/build>.
diff --git a/Building-with-GN.md b/Building-with-GN.md
index cbc7861..4bde55c 100644
--- a/Building-with-GN.md
+++ b/Building-with-GN.md
@@ -1,93 +1 @@
-**Build issues? File a bug at code.google.com/p/v8/issues or ask for help on v8-users@googlegroups.com.**
-
-# Building V8
-
-V8 is built with the help of [GN](https://gn.googlesource.com/gn/+/master/docs/). GN is a meta build system of sorts, as it generates build files for a number of other build systems. How you build therefore depends on what "back-end" build system and compiler you're using.
-The instructions below assume that you already have a [checkout of V8](https://github.com/v8/v8/wiki/Using-Git) but haven't yet installed the build dependencies.
-
-If you intend to develop on V8, i.e., send patches and work with changelists, you’ll need to install the dependencies as described [here](https://github.com/v8/v8/wiki/Using-Git).
-
-More information on GN can be found in [Chromium's documentation](https://www.chromium.org/developers/gn-build-configuration) or [GN's own](https://gn.googlesource.com/gn/+/master/docs/).
-
-## Prerequisite: Build dependencies
-
-All build dependencies are fetched by running:
-
-```gclient sync```
-
-(Only on linux, only needed once) Build dependencies are installed by running:
-
-```./build/install-build-deps.sh```
-
-GN itself is distributed with [`depot_tools`](https://www.chromium.org/developers/how-tos/install-depot-tools).
-
-## Building
-
-There are two workflows for building V8. A raw workflow using commands on a lower level and a convenience workflow using wrapper scripts. There is also convenience all-in-one script that generates build files, triggers the build and optionally also runs the tests.
-
-#### Build instructions (all-in-one script)
-To use the helper script for instance for ```x64.release``` configuration, run:
-
-```tools/dev/gm.py x64.release```
-
-To run the tests right after the build, run:
-
-```tools/dev/gm.py x64.release.check```
-
-This helper script outputs all commands it's executing, so one can easily track them and re-execute if necessary. Using the script it's also possible to build the required binaries and run specific tests with a single command:
-
-```tools/dev/gm.py x64.debug mjsunit/foo cctest/test-bar/*```
-
-#### Build instructions (convenience workflow)
-
-Use a convenience script to generate your build files, e.g.:
-
-```tools/dev/v8gen.py x64.release```
-
-Call ```v8gen.py --help``` for more information. You can add an alias ```v8gen``` calling the script and also use it in other checkouts.
-
-List available configurations (or bots from a master):
-
-```tools/dev/v8gen.py list```
-
-```tools/dev/v8gen.py list -m client.v8```
-
-Build like a particular bot from waterfall `client.v8` in folder `foo`:
-
-```tools/dev/v8gen.py -b "V8 Linux64 - debug builder" -m client.v8 foo```
-
-#### Build instructions (raw workflow)
-
-First, generate the necessary build files:
-
-```gn args out.gn/foo```
-
-An editor will open for specifying the [gn arguments](https://chromium.googlesource.com/chromium/src/+/master/tools/gn/docs/reference.md). You can replace ```foo``` with an arbitrary directory name. Note that due to the conversion from gyp to gn, we use a separate ```out.gn``` folder, to not collide with old gyp folders. If you don't use gyp or keep your subfolders separate, you can also use ```out```.
-
-You can also pass the arguments on the command line:
-
-```gn gen out.gn/foo --args='is_debug=false target_cpu="x64" v8_target_cpu="arm64" use_goma=true'```
-
-This will generate build files for compiling V8 with the arm64 simulator in release mode using goma for compilation. For an overview of all available gn arguments run:
-
-```gn args out.gn/foo --list```
-
-## Compilation
-
-For building all of V8 run (assuming gn generated to the ```x64.release``` folder):
-
-```ninja -C out.gn/x64.release```
-
-To build specific targets like d8, add them to the command line:
-
-```ninja -C out.gn/x64.release d8```
-
-## Testing
-
-You can pass the output directory to the test driver. Other relevant flags will be inferred from the build:
-
-```tools/run-tests.py --outdir out.gn/foo```
-
-You can also test your most recently compiled build (in ```out.gn```):
-
-```tools/run-tests.py --gn```
+# This content has moved to <https://v8.dev/docs/build-gn>.
diff --git a/Building-with-Gyp.md b/Building-with-Gyp.md
index 6841bf1..4bde55c 100644
--- a/Building-with-Gyp.md
+++ b/Building-with-Gyp.md
@@ -1,267 +1 @@
-**Build issues? File a bug at code.google.com/p/v8/issues or ask for help on v8-users@googlegroups.com.**
-
-***
-**GYP has been retired since V8 6.5. Please use [[GN|Building with GN]] instead.**
-***
-# Building V8
-
-V8 is built with the help of [GYP](http://code.google.com/p/gyp/). GYP is a meta build system of sorts, as it generates build files for a number of other build systems. How you build therefore depends on what "back-end" build system and compiler you're using.
-The instructions below assume that you already have a [checkout of V8](Using Git) but haven't yet installed the build dependencies.
-
-If you intend to develop on V8, i.e., send patches and work with changelists, you will need to install the dependencies as described [here](Using Git).
-
-
-## Prerequisite: Installing GYP
-
-First, you need GYP itself. GYP is fetched together with the other dependencies by running:
-
-```
-gclient sync
-```
-
-## Building
-
-### GCC + make
-
-Requires GNU make 3.81 or later. Should work with any GCC >= 4.8 or any recent clang (3.5 highly recommended). For the officially supported clang version please check [V8's DEPS file](https://chromium.googlesource.com/v8/v8/+/master/DEPS).
-
-#### Build instructions
-
-
-The top-level Makefile defines a number of targets for each target architecture (`ia32`, `x64`, `arm`, `arm64`) and mode (`debug`, `optdebug`, or `release`). So your basic command for building is:
-```
-make ia32.release
-```
-
-or analogously for the other architectures and modes. You can build both debug and release binaries with just one command:
-```
-make ia32
-```
-
-To automatically build in release mode for the host architecture:
-```
-make native
-```
-
-You can also can build all architectures in a given mode at once:
-```
-make release
-```
-
-Or everything:
-```
-make
-```
-
-#### Optional parameters
-
- * `-j` specifies the number of parallel build processes. Set it (roughly) to the number of CPU cores your machine has. The GYP/make based V8 build also supports distcc, so you can compile with `-j100` or so, provided you have enough machines around.
-
- * `OUTDIR=foo` specifies where the compiled binaries go. It defaults to `./out/`. In this directory, a subdirectory will be created for each architecture and mode. You will find the d8 shell's binary in `foo/ia32.release/d8`, for example.
-
- * `library=shared` or `component=shared_library` (the two are completely equivalent) builds V8 as a shared library (`libv8.so`).
-
- * `soname_version=1.2.3` is only relevant for shared library builds and configures the SONAME of the library. Both the SONAME and the filename of the library will be `libv8.so.1.2.3` if you specify this. Due to a peculiarity in GYP, if you specify a custom SONAME, the library's path will no longer be encoded in the binaries, so you'll have to run d8 as follows:
-```
-LD_LIBRARY_PATH=out/ia32.release/lib.target out/ia32.release/d8
-```
-
- * `console=readline` enables readline support for the d8 shell. You need readline development headers for this (`libreadline-dev` on Ubuntu).
-
- * `disassembler=on` enables the disassembler for release mode binaries (it's always enabled for debug binaries). This is useful if you want to inspect generated machine code.
-
- * `snapshot=off` disables building with a heap snapshot. Compiling will be a little faster, but V8’s start up will be slightly slower.
-
- * `gdbjit=on` enables GDB JIT support.
-
- * `liveobjectlist=on` enables the Live Object List feature.
-
- * `vfp3=off` is only relevant for ARM builds with snapshot and disables the use of VFP3 instructions in the snapshot.
-
- * `debuggersupport=off` disables the javascript debugger.
-
- * `werror=no` omits the -Werror flag. This is especially useful for not officially supported C++ compilers (e.g. newer versions of the GCC) so that compile warnings are ignored.
-
- * `strictaliasing=off` passes the -fno-strict-aliasing flag to GCC. This may help to work around build failures on officially unsupported platforms and/or GCC versions.
-
- * `regexp=interpreted` chooses the interpreted mode of the irregexp regular expression engine instead of the native code mode.
-
- * `hardfp=on` creates "hardfp" binaries on ARM.
-
-### Ninja
-
-To build d8:
-```
-export GYP_GENERATORS=ninja
-gypfiles/gyp_v8
-ninja -C out/Debug d8
-```
-
-Specify `out/Release` for a release build. I recommend setting up an alias so that you don't need to type out that build directory path.
-
-If you want to build all targets, use `ninja -C out/Debug all`. It's faster to build only the target you're working on, like `d8` or `unittests`.
-
-Note: You need to set `v8_target_arch` if you want a non-native build, i.e. either
-```
-export GYP_DEFINES="v8_target_arch=arm"
-gypfiles/gyp_v8 ...
-```
-or
-```
-gypfiles/gyp_v8 -Dv8_target_arch=arm ...
-```
-
-
-#### Using goma (Googlers only)
-
-To use goma you need to set the `use_goma` gyp define, either by passing it to `gyp_v8`, i.e.
-```
-gypfiles/gyp_v8 -Duse_goma=1
-```
-or by setting the environment variable `$GYP_DEFINES` appropriately:
-```
-export GYP_DEFINES="use_goma=1"
-```
-Note: You may need to also set `gomadir` to point to the directory where you installed goma, if it's not in the default location.
-
-If you are using goma, you'll also want to bump the job limit, i.e.
-```
-ninja -j 100 -C out/Debug d8
-```
-
-
-### Cross-compiling
-
-Similar to building with Clang, you can also use a cross-compiler. Just export your toolchain (`CXX`/`LINK` environment variables should be enough) and compile. For example:
-```
-export CXX=/path/to/cross-compile-g++
-export LINK=/path/to/cross-compile-g++
-make arm.release
-```
-
-
-### Xcode
-
-From the root of your V8 checkout, run either of:
-```
-gypfiles/gyp_v8 -Dtarget_arch=ia32
-gypfiles/gyp_v8 -Dtarget_arch=x64
-```
-
-This will generate Xcode project files in `gypfiles/` that you can then either open with Xcode or compile directly from the command line:
-```
-xcodebuild -project gypfiles/all.xcodeproj -configuration Release
-xcodebuild -project gypfiles/all.xcodeproj
-```
-
-Note: If you have configured your `GYP_GENERATORS` environment variable, either unset it, or set it to `xcode` for this to work.
-
-
-#### Custom build settings
-
-You can export the `GYP_DEFINES` environment variable in your shell to configure custom build options. The syntax is `GYP_DEFINES="-Dvariable1=value1 -Dvariable2=value2"` and so on for as many variables as you wish. Possibly interesting options include:
- * `-Dcomponent=shared_library` (see `library=shared` in the [GCC + make](#optional-parameters) section above)
- * `-Dconsole=readline` (see `console=readline`)
- * `-Dv8_enable_disassembler=1` (see `disassembler=on`)
- * `-Dv8_use_snapshot='false'` (see `snapshot=off`)
- * `-Dv8_enable_gdbjit=1` (see `gdbjit=on`)
- * `-Dv8_use_liveobjectlist=true` (see `liveobjectlist=on`)
-
-
-### Visual Studio
-
-You need Visual Studio 2013, older versions might still work at the moment, but this will probably change soon because we intend to use C++11 features.
-
-#### Prerequisites
-
-If you are a non-googler you need to ```set DEPOT_TOOLS_WIN_TOOLCHAIN=0``` in the CMD. For further information about building on Windows have a look at [Chromium's build instructions](https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md).
-
-After you created [checkout of V8](Using Git), all dependencies will be already installed.
-
-If you are getting errors during build mentioning that 'python' could not be found, add the 'python.exe' to PATH.
-
-If you have Visual Studio 2013 and 2015 installed side-by-side and set the environment variable GYP\_MSVS\_VERSION to '2013'. In that case the right project files are going to be created.
-
-#### Building
- * If you use the command prompt:
- 1. Generate project files:
-```
-set GYP_GENERATORS=ninja
-python gypfiles\gyp_v8
-```
-> > > Specify the path to `python.exe` if you don't have it in your PATH.
-> > > Append `-Dtarget_arch=x64` if you want to build 64bit binaries. If you switch between ia32 and x64 targets, you may have to manually delete the generated .vcproj/.sln files before regenerating them.
-> > > Example:
-```
-third_party/python_26/python.exe gypfiles\gyp_v8 -Dtarget_arch=x64
-```
- 1. Build:
-> > > Either open `build\All.sln` in Visual Studio, or compile on the command line as follows (adapt the path as necessary, or simply put `devenv.com` in your PATH):
-```
-"c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.com" /build Release build\All.sln
-```
-> > > Replace `Release` with `Debug` to build in Debug mode.
-> > > The built binaries will be in build\Release\ or build\Debug\.
-
- * If you use cygwin, the workflow is the same, but the syntax is slightly different:
- 1. Generate project files:
-```
-export GYP_GENERATORS=ninja
-gypfiles/gyp_v8
-```
-> > > This will spit out a bunch of warnings about missing input files, but it seems to be OK to ignore them. (If you have time to figure this out, we'd happily accept a patch that makes the warnings go away!)
- 1. Build:
-```
-/cygdrive/c/Program\ Files\ (x86)/Microsoft\ Visual\ Studio\ 9.0/Common7/IDE/devenv.com /build Release gypfiles/all.sln
-```
-
-
-#### Custom build settings
-
-See the "custom build settings" section for [Xcode](#xcode) above.
-
-
-#### Running tests
-
-You can abuse the test driver's --buildbot flag to make it find the executables where MSVC puts them:
-```
-python tools/run-tests.py --buildbot --outdir build --arch ia32 --mode Release
-```
-
-
-### MinGW
-
-Building on MinGW is not officially supported, but it is possible. You even have two options:
-
-#### Option 1: With Cygwin Installed
-
-Requirements:
- * MinGW
- * Cygwin, including Python
- * Python from www.python.org _(yes, you need two Python installations!)_
-
-Building:
- 1. Open a MinGW shell
- 1. `export PATH=$PATH:/c/cygwin/bin` _(or wherever you installed Cygwin)_
- 1. `make ia32.release -j8`
-
-Running tests:
- 1. Open a MinGW shell
- 1. `export PATH=/c/Python27:$PATH` _(or wherever you installed Python)_
- 1. `make ia32.release.check -j8`
-
-#### Option 2: Without Cygwin, just MinGW
-
-Requirements:
- * MinGW
- * Python from www.python.org
-
-Building and testing:
- 1. Open a MinGW shell
- 1. `tools/mingw-generate-makefiles.sh` _(re-run this any time a `*`.gyp`*` file changed, such as after updating your checkout)_
- 1. `make ia32.release` _(unfortunately -jX doesn't seem to work here)_
- 1. `make ia32.release.check -j8`
-
-
-# Final Note
-<b>If you have problems or questions, please [file bugs](https://bugs.chromium.org/p/v8/issues/list) or send an email to v8-users@googlegroups.com.</b>
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/build-gn>.
diff --git a/Built-in-functions.md b/Built-in-functions.md
index 45edee9..9a0a768 100644
--- a/Built-in-functions.md
+++ b/Built-in-functions.md
@@ -1,5 +1 @@
-Built-in functions in V8 come in different flavors wrt implementation, depending on their functionality, performance requirements, and sometimes plain historical development.
-
-Some are implemented in JavaScript directly, and are compiled into executable code at runtime just like any user JavaScript. Some of them resort to so-called _runtime functions_ for part of their functionality. Runtime functions are written in C++ and called from JavaScript through a "%"-prefix. Usually, these runtime functions are limited to V8 internal JavaScript code. For debugging purposes, they can also be called from normal JavaScript code, if V8 is run with the flag --allow-natives-syntax. Some runtime functions are directly embedded by the compiler into generated code. For a list, see src/runtime/runtime.h.
-
-Other functions are implemented as _built-ins_, which themselves can be implemented in a number of different ways. Some are implemented directly in platform-dependent assembly. Some are implemented in _CodeStubAssembler_, a platform-independent abstraction. Yet others are directly implemented in C++. Built-ins are sometimes also used to implement pieces of glue code, not necessarily entire functions. For a list, see src/builtins/builtins.h.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/builtin-functions>.
diff --git a/Checking-out-source.md b/Checking-out-source.md
index cd96a2b..81ff22f 100644
--- a/Checking-out-source.md
+++ b/Checking-out-source.md
@@ -1,19 +1 @@
-
-**Quick links:** [browse](https://chromium.googlesource.com/v8/v8/) | [browse bleeding edge](https://chromium.googlesource.com/v8/v8/+/master) | [changes](https://chromium.googlesource.com/v8/v8/+log/master).
-
-# Command-Line Access
-
-## Git
-See [[Using Git|Using Git]].
-
-# Source Code Branches
-
-There are several different branches of V8; if you're unsure of which version to get, you most likely want the up-to-date stable version. Have a look at our [[Release Process|Release Process]] for more information about the different branches used.
-
-You may want to follow the V8 version that Chrome is shipping on its stable (or beta) channels, see http://omahaproxy.appspot.com.
-
-# V8 public API compatibility
-
-V8 public API (basically the files under include/ directory) may change over time. New types/methods may be added without breaking existing functionality. When we decide that want to drop some existing class/methods, we first mark it with [V8\_DEPRECATED](https://code.google.com/p/chromium/codesearch#search/&q=V8_DEPRECATED&sq=package:chromium&type=cs) macro which will cause compile time warnings when the deprecated methods are called by the embedder. We keep deprecated method for one branch and then remove it. E.g. if `v8::CpuProfiler::FindCpuProfile` was plain non deprecated in _3.17_ branch, marked as `V8_DEPRECATED` in _3.18_, it may well be removed in _3.19_ branch.
-
-We also maintain a [document mentioning important API changes](https://docs.google.com/document/d/1g8JFi8T_oAE_7uAri7Njtig7fKaPDfotU6huOa1alds/edit) for each version.
+# This content has moved to <https://v8.dev/docs/source-code>.
diff --git a/Code-of-conduct.md b/Code-of-conduct.md
index bd511df..cf35200 100644
--- a/Code-of-conduct.md
+++ b/Code-of-conduct.md
@@ -1 +1 @@
-As part of the Chromium team, the V8 team is committed to preserving and fostering a diverse, welcoming community. To this end, the [Chromium Code of Conduct](https://chromium.googlesource.com/chromium/src/+/master/CODE_OF_CONDUCT.md) applies to our repos and organizations, mailing lists, blog content, and any other Chromium-supported communication group, as well as any private communication initiated in the context of these spaces
\ No newline at end of file
+# This content has moved to <https://v8.dev/terms#code-of-conduct>.
diff --git a/CodeStubAssembler-Builtins.md b/CodeStubAssembler-Builtins.md
index bf69d99..827a3cc 100644
--- a/CodeStubAssembler-Builtins.md
+++ b/CodeStubAssembler-Builtins.md
@@ -1,217 +1 @@
-This document is intended as an introduction to writing CodeStubAssembler builtins, and is targeted towards V8 developers.
-
-# Builtins
-
-In V8, builtins can be seen as chunks of code that are executable by the VM at runtime. A common use case is to implement the functions of builtin objects (such as RegExp or Promise), but builtins can also be used to provide other internal functionality (e.g. as part of the IC system).
-
-V8’s builtins can be implemented using a number of different methods (each with different trade-offs):
-* **Platform-dependent assembly language**: can be highly efficient, but need manual ports to all platforms and are difficult to maintain.
-* **C++**: very similar in style to runtime functions and have access to V8’s powerful runtime functionality, but usually not suited to performance-sensitive areas.
-* **JavaScript**: concise and readable code, access to fast intrinsics, but frequent usage of slow runtime calls, subject to unpredictable performance through type pollution, and subtle issues around (complicated and non-obvious) JS semantics.
-* **CodeStubAssembler**: provides efficient low-level functionality that is very close to assembly language while remaining platform-independent and preserving readability.
-
-The remaining document will focus on the latter and give a brief tutorial for developing a simple CodeStubAssembler (CSA) builtin exposed to JavaScript.
-
-# CodeStubAssembler
-
-V8’s CodeStubAssembler is a custom, platform-agnostic assembler that provides low-level primitives as a thin abstraction over assembly, but also offers an extensive library of higher-level functionality.
-
-```c++
-// Low-level:
-// Loads the pointer-sized data at addr into value.
-Node* addr = /* ... */;
-Node* value = Load(MachineType::IntPtr(), addr);
-
-// And high-level:
-// Performs the JS operation ToString(object).
-// ToString semantics are specified at https://tc39.github.io/ecma262/#sec-tostring.
-Node* object = /* ... */;
-Node* string = ToString(context, object);
-```
-
-CSA builtins run through part of the TurboFan compilation pipeline (including block scheduling and register allocation, but notably not through optimization passes) which then emits the final executable code.
-
-# Writing a CodeStubAssembler Builtin
-
-In this section, we will write a simple CSA builtin that takes a single argument, and returns whether it represents the number `42`. The builtin will be exposed to JS by installing it on the `Math` object (because we can).
-
-This example demonstrates:
-* Creating a CSA builtin with JavaScript linkage, which can be called like a JS function.
-* Using CSA to implement simple logic: Smi and heap-number handling, conditionals, and calls to TFS builtins.
-* Using CSA Variables.
-* Installation of the CSA builtin on the `Math` object.
-
-In case you’d like to follow along locally, the following code is based off revision [7a8d20a7](https://chromium.googlesource.com/v8/v8/+/7a8d20a79f9d5ce6fe589477b09327f3e90bf0e0).
-
-## Declaring MathIs42
-
-Builtins are declared in the `BUILTIN_LIST_BASE` macro in [`src/builtins/builtins-definitions.h`](https://cs.chromium.org/chromium/src/v8/src/builtins/builtins-definitions.h?q=builtins-definitions.h+package:%5Echromium$&l=1). To create a new CSA builtin with JS linkage and one parameter named `X`:
-
-```c++
-#define BUILTIN_LIST_BASE(CPP, API, TFJ, TFC, TFS, TFH, ASM, DBG) \
- // [... snip ...]
- TFJ(MathIs42, 1, kX) \
- // [... snip ...]
-```
-
-Note that `BUILTIN_LIST_BASE` takes several different macros that denote different builtin kinds (see inline documentation for more details). CSA builtins specifically are split into:
-* **TFJ**: JavaScript linkage.
-* **TFS**: Stub linkage.
-* **TFC**: Stub linkage builtin requiring a custom interface descriptor (e.g. if arguments are untagged or need to be passed in specific registers).
-* **TFH**: Specialized stub linkage builtin used for IC handlers.
-
-## Defining MathIs42
-
-Builtin definitions are located in `src/builtins/builtins-*-gen.cc` files, roughly organized by topic. Since we will be writing a `Math` builtin, we’ll put our definition into [`src/builtins/builtins-math-gen.cc`](https://cs.chromium.org/chromium/src/v8/src/builtins/builtins-math-gen.cc?q=builtins-math-gen.cc+package:%5Echromium$&l=1).
-
-```c++
-// TF_BUILTIN is a convenience macro that creates a new subclass of the given
-// assembler behind the scenes.
-TF_BUILTIN(MathIs42, MathBuiltinsAssembler) {
- // Load the current function context (an implicit argument for every stub)
- // and the X argument. Note that we can refer to parameters by the names
- // defined in the builtin declaration.
- Node* const context = Parameter(Descriptor::kContext);
- Node* const x = Parameter(Descriptor::kX);
-
- // At this point, x can be basically anything - a Smi, a HeapNumber,
- // undefined, or any other arbitrary JS object. Let’s call the ToNumber
- // builtin to convert x to a number we can use.
- // CallBuiltin can be used to conveniently call any CSA builtin.
- Node* const number = CallBuiltin(Builtins::kToNumber, context, x);
-
- // Create a CSA variable to store the resulting value. The type of the
- // variable is kTagged since we will only be storing tagged pointers in it.
- VARIABLE(var_result, MachineRepresentation::kTagged);
-
- // We need to define a couple of labels which will be used as jump targets.
- Label if_issmi(this), if_isheapnumber(this), out(this);
-
- // ToNumber always returns a number. We need to distinguish between Smis
- // and heap numbers - here, we check whether number is a Smi and conditionally
- // jump to the corresponding labels.
- Branch(TaggedIsSmi(number), &if_issmi, &if_isheapnumber);
-
- // Binding a label begins generating code for it.
- BIND(&if_issmi);
- {
- // SelectBooleanConstant returns the JS true/false values depending on
- // whether the passed condition is true/false. The result is bound to our
- // var_result variable, and we then unconditionally jump to the out label.
- var_result.Bind(SelectBooleanConstant(SmiEqual(number, SmiConstant(42))));
- Goto(&out);
- }
-
- BIND(&if_isheapnumber);
- {
- // ToNumber can only return either a Smi or a heap number. Just to make sure
- // we add an assertion here that verifies number is actually a heap number.
- CSA_ASSERT(this, IsHeapNumber(number));
- // Heap numbers wrap a floating point value. We need to explicitly extract
- // this value, perform a floating point comparison, and again bind
- // var_result based on the outcome.
- Node* const value = LoadHeapNumberValue(number);
- Node* const is_42 = Float64Equal(value, Float64Constant(42));
- var_result.Bind(SelectBooleanConstant(is_42));
- Goto(&out);
- }
-
- BIND(&out);
- {
- Node* const result = var_result.value();
- CSA_ASSERT(this, IsBoolean(result));
- Return(result);
- }
-}
-```
-
-## Attaching Math.Is42
-
-Builtin objects such as `Math` are set up mostly in [`src/bootstrapper.cc`](https://cs.chromium.org/chromium/src/v8/src/bootstrapper.cc?q=src/bootstrapper.cc+package:%5Echromium$&l=1) (with some setup occurring in `.js` files). Attaching our new builtin is simple:
-
-```c++
-// Existing code to set up Math, included here for clarity.
-Handle<JSObject> math = factory->NewJSObject(cons, TENURED);
-JSObject::AddProperty(global, name, math, DONT_ENUM);
-// [... snip ...]
-SimpleInstallFunction(math, "is42", Builtins::kMathIs42, 1, true);
-```
-
-Now that Is42 is attached, it can be called from JS:
-
-```
-$ out/debug/d8
-d8> Math.is42(42)
-true
-d8> Math.is42("42.0")
-true
-d8> Math.is42(true)
-false
-d8> Math.is42({ valueOf: () => 42 })
-true
-```
-
-## Defining and calling a builtin with stub linkage
-
-CSA builtins can also be created with stub linkage (instead of JS linkage as we used above in `MathIs42`). Such builtins can be useful to extract commonly-used code into a separate code object that can be used by multiple callers, while the code is only produced once. Let’s extract the code that handles heap numbers into a separate builtin called `MathIsHeapNumber42`, and call it from `MathIs42`.
-
-Defining and using TFS stubs is easy; declaration are again placed in [`src/builtins/builtins-definitions.h`](https://cs.chromium.org/chromium/src/v8/src/builtins/builtins-definitions.h?q=builtins-definitions.h+package:%5Echromium$&l=1):
-
-```C++
-#define BUILTIN_LIST_BASE(CPP, API, TFJ, TFC, TFS, TFH, ASM, DBG) \
- // [... snip ...]
- TFS(MathIsHeapNumber42, kX) \
- TFJ(MathIs42, 1, kX) \
- // [... snip ...]
-```
-
-Note that currently, order within `BUILTIN_LIST_BASE` does matter. Since `MathIs42` calls `MathIsHeapNumber42`, the former needs to be listed after the latter (this requirement should be lifted at some point).
-
-The definition is also straightforward. In [`src/builtins/builtins-math-gen.cc`](https://cs.chromium.org/chromium/src/v8/src/builtins/builtins-math-gen.cc?q=builtins-math-gen.cc+package:%5Echromium$&l=1):
-
-```C++
-// Defining a TFS builtin works exactly the same way as TFJ builtins.
-TF_BUILTIN(MathIsHeapNumber42, MathBuiltinsAssembler) {
- Node* const x = Parameter(Descriptor::kX);
- CSA_ASSERT(this, IsHeapNumber(x));
- Node* const value = LoadHeapNumberValue(x);
- Node* const is_42 = Float64Equal(value, Float64Constant(42));
- Return(SelectBooleanConstant(is_42));
-}
-```
-
-Finally, let’s call our new builtin from `MathIs42`:
-
-```C++
-TF_BUILTIN(MathIs42, MathBuiltinsAssembler) {
- // [... snip ...]
- BIND(&if_isheapnumber);
- {
- // Instead of handling heap numbers inline, we now call into our new TFS stub.
- var_result.Bind(CallBuiltin(Builtins::kMathIsHeapNumber42, context, number));
- Goto(&out);
- }
- // [... snip ...]
-}
-```
-
-Why should you care about TFS builtins at all? Why not leave the code inline (or extracted into a helper method for better readability)?
-
-An important reason is code space: builtins are generated at compile-time and included in the V8 snapshot, thus unconditionally taking up (significant) space in every created isolate. Extracting large chunks of commonly used code to TFS builtins can quickly lead to space savings in the 10s to 100s of KBs.
-
-## Testing stub-linkage builtins
-
-Even though our new builtin uses a non-standard (at least non-C++) calling convention, it’s possible to write test cases for it. The following code can be added to [`test/cctest/compiler/test-run-stubs.cc`](https://cs.chromium.org/chromium/src/v8/test/cctest/compiler/test-run-stubs.cc?l=1&rcl=4cab16db27808cf66ab883e7904f1891f9fd0717) to test the builtin on all platforms:
-
-```C++
-TEST(MathIsHeapNumber42) {
- HandleAndZoneScope scope;
- Isolate* isolate = scope.main_isolate();
- Heap* heap = isolate->heap();
- Zone* zone = scope.main_zone();
-
- StubTester tester(isolate, zone, Builtins::kMathIs42);
- Handle<Object> result1 = tester.Call(Handle<Smi>(Smi::FromInt(0), isolate));
- CHECK(result1->BooleanValue());
-}
-```
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/csa-builtins>.
diff --git "a/Committer\047s-responsibility.md" "b/Committer\047s-responsibility.md"
index 58c65f9..1d64c11 100644
--- "a/Committer\047s-responsibility.md"
+++ "b/Committer\047s-responsibility.md"
@@ -1,37 +1 @@
-# Basic commit guidelines
-
-When you're committing to the V8 repositories, ensure that you follow those guidelines:
-
- 1. Find the right reviewer for your changes and for patches you're asked to review.
- 1. Be available on IM and/or email before and after you land the change.
- 1. Watch the [waterfall](http://build.chromium.org/p/client.v8/console) until all bots turn green after your change.
- 1. When landing a TBR change (To Be Reviewed), make sure to notify the people whose code you're changing. Usually just send the review e-mail.
-
-In short, do the right thing for the project, not the easiest thing to get code committed, and above all: use your best judgement.
-
-**Don't be afraid to ask questions. There is always someone who will immediately read messages sent to the v8-committers mailing list who can help you.**
-
-# Changes with multiple reviewers
-
-There are occasionally changes with a lot of reviewers on them, since sometimes several people might need to be in the loop for a change because of multiple areas of responsibility and expertise.
-
-The problem is that without some guidelines, there's no clear responsibility given in these reviews.
-
-If you're the sole reviewer on a change, you know you have to do a good job. When there are three other people, you sometimes assume that somebody else must have looked carefully at some part of the review. Sometimes all the reviewers think this and the change isn't reviewed properly.
-
-In other cases, some reviewers say "LGTM" for a patch, while others are still expecting changes. The author can get confused as to the status of the review, and some patches have been checked in where at least one reviewer expected further changes before committing.
-
-At the same time, we want to encourage many people to participate in the review process and keep tabs on what's going on.
-
-So, here are some guidelines to help clarify the process:
- 1. When a patch author requests more than one reviewer, they should make clear in the review request email what they expect the responsibility of each reviewer to be. For example, you could write this in the email:
- * larry: bitmap changes
- * sergey: process hacks
- * everybody else: FYI
- 1. In this case, you might be on the review list because you've asked to be in the loop for multiprocess changes, but you wouldn't be the primary reviewer and the author and other reviewers wouldn't be expecting you to review all the diffs in detail.
- 1. If you get a review that includes many other people, and the author didn't do (1), please ask them what part you're responsible for if you don't want to review the whole thing in detail.
- 1. The author should wait for approval from everybody on the reviewer list before checking in.
- 1. People who are on a review without clear review responsibility (i.e. drive-by reviews) should be super responsive and not hold up the review. The patch author should feel free to ping them mercilessly if they are.
- 1. If you're an "FYI" person on a review and you didn't actually review in detail (or at all), but don't have a problem with the patch, note this. You could say something like "rubber stamp" or "ACK" instead of "LGTM." This way the real reviewers know not to trust that you did their work for them, but the author of the patch knows they don't have to wait for further feedback from you. Hopefully we can still keep everybody in the loop but have clear ownership and detailed reviews. It might even speed up some changes since you can quickly "ACK" changes you don't care about, and the author knows they don't have to wait for feedback from you.
-
-(Adapted from: http://dev.chromium.org/developers/committers-responsibility )
+# This content has moved to <https://v8.dev/docs/committer-responsibility>.
diff --git a/Contributing.md b/Contributing.md
index 5a9cba8..f486e31 100644
--- a/Contributing.md
+++ b/Contributing.md
@@ -1,37 +1 @@
-The information on this page explains how to contribute to V8. Be sure to read the whole thing — including the small print at the end — before sending us a contribution.
-
-# Get the code
-
-See [Checking out source](https://github.com/v8/v8/wiki/Checking-out-source).
-
-# Before you contribute
-
-## Ask on V8’s mailing list for guidance
-
-Before you start working on a larger contribution V8, you should get in touch with us first through [the V8 contributor mailing list](https://groups.google.com/group/v8-dev) so we can help out and possibly guide you. Coordinating up front makes it much easier to avoid frustration later on.
-
-## Sign the CLA
-
-Before we can use your code you have to sign the [Google Individual Contributor License Agreement](https://cla.developers.google.com/about/google-individual), which you can do online. This is mainly because you own the copyright to your changes, even after your contribution becomes part of our codebase, so we need your permission to use and distribute your code. We also need to be sure of various other things, for instance that you’ll tell us if you know that your code infringes on other people’s patents. You don’t have to do this until after you’ve submitted your code for review and a member has approved it, but you will have to do it before we can put your code into our codebase.
-
-Contributions made by corporations are covered by a different agreement than the one above, the [Software Grant and Corporate Contributor License Agreement](https://cla.developers.google.com/about/google-corporate).
-
-Sign them online [here](https://cla.developers.google.com/).
-
-# Submit your code
-
-The source code of V8 follows the [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html) so you should familiarize yourself with those guidelines. Before submitting code you must pass all our [tests](Testing), and have to successfully run the presubmit checks:
-
-```sh
-tools/presubmit.py
-```
-
-The presubmit script uses a linter from Google, `cpplint.py`. External contributors can get this from [here](https://raw.githubusercontent.com/google/styleguide/gh-pages/cpplint/cpplint.py) and place it in their path.
-
-## Upload to V8’s codereview tool
-
-All submissions, including submissions by project members, require review. We use the same code-review tools and process as the Chromium project. In order to submit a patch, you need to get the [`depot_tools`](https://dev.chromium.org/developers/how-tos/install-depot-tools) and follow these instructions on [requesting a review](https://dev.chromium.org/developers/contributing-code) (using your V8 workspace instead of a Chromium workspace).
-
-## Look out for breakage or regressions
-
-Before submitting your code please check [the buildbot console](https://build.chromium.org/p/client.v8/console) to see that the columns are mostly green before checking in your changes — otherwise you will not know if your changes break the build or not. When your change is committed, watch [the buildbot console](https://build.chromium.org/p/client.v8/console) until the bots turn green after your change.
+# This content has moved to <https://v8.dev/docs/contribute>.
diff --git a/Cross-compiling-for-ARM.md b/Cross-compiling-for-ARM.md
index 15b437e..9f7feed 100644
--- a/Cross-compiling-for-ARM.md
+++ b/Cross-compiling-for-ARM.md
@@ -1,82 +1 @@
-# Cross-compiling with GN
-
-First, make sure you can [build with GN](Building with GN).
-
-Then, add android to your `.gclient` configuration file.
-
- target_os = ['android'] # Add this to get Android stuff checked out.
-
-The `target_os` field is a list, so if you're also building on unix it'll look like this:
-
- target_os = ['android', 'unix'] # multiple target oses
-
-Run `gclient sync`, and you'll get a large checkout under `./third_party/android_tools`.
-
-Enable developer mode on your phone or tablet, and turn on USB debugging, via instructions [here](https://developer.android.com/studio/run/device.html). Also, get the handy [adb](https://developer.android.com/studio/command-line/adb.html) tool on your path. It's in your checkout at `./third_party/android_tools/sdk/platform-tools`.
-
-Use `v8gen.py` to generate an arm release or debug build:
-
- tools/dev/v8gen.py arm.release
-
-Then run `gn args out.gn/arm.release' and make sure you have the following keys:
-
- target_os = "android" # These lines need to be changed manually
- target_cpu = "arm" # as v8gen.py assumes a simulator build.
- v8_target_cpu = "arm"
- is_component_build = false
-
-The keys should be the same for debug builds. If you are building for an arm64 device like the Pixel C, which supports 32bit and 64bit binaries, the keys should look like this:
-
- target_os = "android" # These lines need to be changed manually
- target_cpu = "arm64" # as v8gen.py assumes a simulator build.
- v8_target_cpu = "arm64"
- is_component_build = false
-
-Now build:
-
- ninja -C out.gn/arm.release d8
-
-Using adb copy the binary and snapshot files to the phone:
-
- adb push out.gn/arm.release/d8 /data/local/tmp
- adb push out.gn/arm.release/natives_blob.bin /data/local/tmp
- adb push out.gn/arm.release/snapshot_blob.bin /data/local/tmp
-
-
- rebuffat:~/src/v8$ adb shell
- bullhead:/ $ cd /data/local/tmp
- bullhead:/data/local/tmp $ ls
- v8 natives_blob.bin snapshot_blob.bin
- bullhead:/data/local/tmp $ ./d8
- V8 version 5.8.0 (candidate)
- d8> 'w00t!'
- "w00t!"
- d8>
-
-# Building with Gyp
-
-See [Building with Gyp](Building with Gyp) for more information on how to build.
-
-# Using Sourcery G++ Lite
-
-The Sourcery G++ Lite cross compiler suite is a free version of Sourcery G++ from [CodeSourcery](http://www.codesourcery.com). There is a page for the [GNU Toolchain for ARM Processors](http://www.codesourcery.com/sgpp/lite/arm). Determine the version you need for your host/target combination.
-
-The following instructions uses [2009q1-203 for ARM GNU/Linux](http://www.codesourcery.com/sgpp/lite/arm/portal/release858), and if using a different version please change the URLs and `TOOL_PREFIX` below accordingly.
-
-## Installing on host and target
-
-The simplest way of setting this up is to install the full Sourcery G++ Lite package on both the host and target at the same location. This will ensure that all the libraries required are available on both sides. If you want to use the default libraries on the host there is no need the install anything on the target.
-
-The following script will install in `/opt/codesourcery`:
-
-```
-#!/bin/sh
-
-sudo mkdir /opt/codesourcery
-cd /opt/codesourcery
-sudo chown $USERNAME .
-chmod g+ws .
-umask 2
-wget http://www.codesourcery.com/sgpp/lite/arm/portal/package4571/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
-tar -xvf arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
-```
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/cross-compile-arm>.
diff --git a/D8-on-Android.md b/D8-on-Android.md
index b444c60..2a71ed4 100644
--- a/D8-on-Android.md
+++ b/D8-on-Android.md
@@ -1,118 +1 @@
-# Prerequisites
- * a Linux/Mac workstation
- * v8 r12178 (on Google Code) or later
- * an Android emulator or device with matching USB cable
- * make sure [building with GYP](https://github.com/v8/v8/wiki/Building%20with%20Gyp) works
- * [Mac-only] [Download the NDK](http://developer.android.com/ndk/downloads/index.html) and note the path where it is installed.
-
-
-# Get the code
-
- * Use the instructions from [Using Git](Using Git) to get the code
- * Once you need to add the android dependencies:
-```
-v8$ echo "target_os = ['android']" >> ../.gclient && gclient sync --nohooks
-```
- * The sync will take a while the first time as it downloads the Android NDK to v8/third\_party
- * If you want to use a different NDK, or you are building on Mac where you *must* supply your own NDK, you need to pass the path to your NDK installation when issuing running make.
-```
- make android_arm.release -j16 android_ndk_root=[full path to ndk]
-```
-
-
-# Get the Android SDK
- * tested version: `r15`
- * download the SDK from http://developer.android.com/sdk/index.html
- * extract it
- * install the "Platform tools" using the SDK manager that you can start by running `tools/android`
- * now you have a `platform_tools/adb` binary which will be used later; put it in your `PATH` or remember where it is
-
-
-# Set up your device
- * Enable USB debugging (Gingerbread: Settings > Applications > Development > USB debugging; Ice Cream Sandwich: Settings > Developer Options > USB debugging)
- * connect your device to your workstation
- * make sure `adb devices` shows it; you may have to edit `udev` rules to give yourself proper permissions
- * run `adb shell` to get an ssh-like shell on the device. In that shell, do:
-```
-cd /data/local/tmp
-mkdir v8
-cd v8
-```
-
-
-# Push stuff onto the device
- * make sure your device is connected
- * from your workstation's shell:
-```
-adb push /file/you/want/to/push /data/local/tmp/v8/
-```
-
-
-# Compile V8 for Android
-gn args should specify:
-```
-is_component_build = false
-target_cpu = "arm"
-target_os = "android"
-v8_android_log_stdout = true
-```
-
-You may use goma, and specify debug or not, and symbol levels, as usual.
-
-Assuming you build to out/android_arm.release, copy the binaries and support files over:
-
-```
-adb push out/android_arm.release/d8 /data/local/tmp/v8/d8
-adb push out/android_arm.release/snapshot_blob.bin /data/local/tmp/v8/
-adb push out/android_arm.release/natives_blob.bin /data/local/tmp/v8/
-```
-The most comfortable way to run it is from your workstation's shell as a one-off command (rather than starting an interactive shell session on the device), that way you can use pipes or whatever to process the output as necessary:
-```
-adb shell /data/local/tmp/v8/d8 <parameters>
-```
- * warning: when you cancel such an "adb shell whatever" command using Ctrl+C, the process on the phone will sometimes keep running.
-
-
-# Profile
- * compile a binary, push it to the device, keep a copy of it on the host
-```
-ninja -C android_arm.release
-adb push out/android_arm.release/d8 /data/local/tmp/v8/d8-version.under.test
-cp out/android_arm.release/d8 ./d8-version.under.test
-```
- * get a profiling log and copy it to the host:
-```
-adb shell /data/local/tmp/v8/d8-version.under.test benchmark.js --prof
-adb pull /data/local/tmp/v8/v8.log ./
-```
- * open `v8.log` in your favorite editor and edit the first line to match the full path of the `d8-version.under.test` binary on your workstation (instead of the `/data/local/tmp/v8/` path it had on the device)
- * run the tick processor with the host's `d8` and an appropriate `nm` binary:
-```
-cp out/ia32.release/d8 ./d8 # only required once
-tools/linux-tick-processor --nm=$ANDROID_NDK_ROOT/toolchain/bin/arm-linux-androideabi-nm
-```
-
-
-# Using the Static Libraries
-
-The static libraries created by the build process are found in `out/android_arm.release/obj.target/tools/gyp/`. They are "thin" archives, which means that the .a files contain symbolic links to the .o files used to make the archive. This makes these libraries unusable on any machine but the one that built the library.
-
-A program linking with V8 must link with `libv8_libplatform.a` `libv8_base.a` `libv8_libbase.a` and one of the snapshot libaries such as`libv8_nosnapshot.a` that will be produced if V8 is compiled with the `snapshot=off` option.
-
-Unless V8 was compiled with `i18nsupport=off` option the program must also link with the International Components for Unicode (ICU) library found in `out/android_arm.release/obj.target/third_party/icu/`.
-
-# Compile SpiderMonkey for Lollipop
-```
-cd firefox/js/src
-autoconf2.13
-./configure \
- --target=arm-linux-androideabi \
- --with-android-ndk=$ANDROID_NDK_ROOT \
- --with-android-version=21 \
- --without-intl-api \
- --disable-tests \
- --enable-android-libstdcxx \
- --enable-pie
-make
-adb push -p js/src/shell/js /data/local/tmp/js
-```
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/d8-android>.
diff --git a/Debugging-Builtins-with-GDB.md b/Debugging-Builtins-with-GDB.md
index 7685e86..0bba60e 100644
--- a/Debugging-Builtins-with-GDB.md
+++ b/Debugging-Builtins-with-GDB.md
@@ -1,36 +1 @@
-As of V8 v6.9, there's a more convenient way to debug CSA / ASM / Torque builtins in GDB (and possibly other debuggers).
-
-It's now possible to create breakpoints from within GDB:
-
-```
-(gdb) br i::Isolate::Init
-Breakpoint 1 at 0x7ffff706742b: i::Isolate::Init. (2 locations)
-(gdb) r
-Thread 1 "d8" hit Breakpoint 1, 0x00007ffff7c55bc0 in Isolate::Init
-(gdb) dis 1
-(gdb) br Builtins_RegExpPrototypeExec
-Breakpoint 2 at 0x7ffff7ac8784
-(gdb) c
-Thread 1 "d8" hit Breakpoint 2, 0x00007ffff7ac8784 in Builtins_RegExpPrototypeExec ()
-```
-
-Builtins are also visible in stack traces:
-
-```
-(gdb) bt
-#0 0x00007ffff7ac8784 in Builtins_RegExpPrototypeExec ()
-#1 0x00007ffff78f5066 in Builtins_ArgumentsAdaptorTrampoline ()
-#2 0x000039751d2825b1 in ?? ()
-#3 0x000037ef23a0fa59 in ?? ()
-#4 0x0000000000000000 in ?? ()
-```
-
-Caveats:
-- Only works with embedded builtins (no ia32 yet, sorry).
-- Breakpoints can only be set at the start of the builtin.
-- The initial breakpoint in `Isolate::Init` is needed prior to setting the builtin breakpoint, since GDB modifies the binary and we verify a hash of the builtins section in the binary at startup. Otherwise, V8 complains about a hash mismatch:
-
- ```
- # Fatal error in ../../src/isolate.cc, line 117
- # Check failed: d.Hash() == d.CreateHash() (11095509419988753467 vs. 3539781814546519144).
- ```
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/gdb>.
diff --git a/Debugging-over-the-V8-Inspector-API.md b/Debugging-over-the-V8-Inspector-API.md
index 6ce571c..ea6fe67 100644
--- a/Debugging-over-the-V8-Inspector-API.md
+++ b/Debugging-over-the-V8-Inspector-API.md
@@ -1,69 +1 @@
-# Introduction
-
-V8 provides extensive debugging functionality to both users and embedders. Users will usually interact with the V8 debugger through the [Chrome Devtools](https://developer.chrome.com/devtools) interface. Embedders (including Devtools) need to rely directly on the [Inspector Protocol](https://chromedevtools.github.io/debugger-protocol-viewer/tot/).
-
-This page is intended to give embedders the basic tools they need to implement debugging support in V8.
-
-# Connecting to Inspector
-
-V8's [command-line debug shell d8](Using-D8) includes a simple inspector integration through the [InspectorFrontend](https://cs.chromium.org/chromium/src/v8/src/d8.cc?type=cs&q=InspectorFrontend+package:%5Echromium$&l=1849) and [InspectorClient](https://cs.chromium.org/chromium/src/v8/src/d8.cc?type=cs&q=InspectorClient+package:%5Echromium$&l=1916). The client sets up a communication channel for messages sent from the embedder to V8 in
-
-```c++
- static void SendInspectorMessage(
- const v8::FunctionCallbackInfo<v8::Value>& args) {
- // [...] Create a StringView that Inspector can understand.
- session->dispatchProtocolMessage(message_view);
- }
-```
-
-while the frontend establishes a channel for messages sent from V8 to the embedder by implementing
-sendResponse and sendNotification, which then forward to:
-
-```c++
- void Send(const v8_inspector::StringView& string) {
- // [...] String transformations.
- // Grab the global property called 'receive' from the current context.
- Local<String> callback_name =
- v8::String::NewFromUtf8(isolate_, "receive", v8::NewStringType::kNormal)
- .ToLocalChecked();
- Local<Context> context = context_.Get(isolate_);
- Local<Value> callback =
- context->Global()->Get(context, callback_name).ToLocalChecked();
- // And call it to pass the message on to JS.
- if (callback->IsFunction()) {
- // [...]
- MaybeLocal<Value> result = Local<Function>::Cast(callback)->Call(
- context, Undefined(isolate_), 1, args);
- }
- }
-```
-
-# Using the Inspector Protocol
-
-Continuing with our example, d8 forwards inspector messages to JavaScript. The following code implements a basic, but fully functional interaction with inspector through d8:
-
-```js
-// inspector-demo.js
-// Receiver function called by d8.
-function receive(message) {
- print(message)
-}
-
-const msg = JSON.stringify({
- id: 0,
- method: "Debugger.enable",
- });
-
-// Call the function provided by d8.
-send(msg);
-
-// Run this file by executing 'd8 --enable-inspector inspector-demo.js'.
-```
-
-# Further Documentation
-
-A more fleshed-out example of Inspector API usage is available at [test-api.js](https://cs.chromium.org/chromium/src/v8/test/debugger/test-api.js?type=cs&q=test-api&l=1), which implements a simple debugging API for use by V8's test suite.
-
-V8 also contains an alternative Inspector integration at [inspector-test.cc](https://cs.chromium.org/chromium/src/v8/test/inspector/inspector-test.cc?q=inspector-te+package:%5Echromium$&l=1).
-
-The Chrome Devtools wiki provides [full documentation](https://chromedevtools.github.io/debugger-protocol-viewer/tot/) of all available functions.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/inspector>.
diff --git a/Design-Elements.md b/Design-Elements.md
index 9a562db..dbcca19 100644
--- a/Design-Elements.md
+++ b/Design-Elements.md
@@ -1,89 +1 @@
-**_Disclaimer: A lot of the information on this page is not accurate anymore._**
-
-***
-
-
-JavaScript's integration with Netscape Navigator in the mid 1990s made it much easier for web developers to access HTML page elements such as forms, frames, and images. JavaScript quickly became popular for customizing controls and adding animation and by the late 1990s the vast majority of scripts simply swapped one image for another in response to user-generated mouse events.
-
-More recently, following the arrival of AJAX, JavaScript has become a central technology for implementing web-based applications such as our very own GMail. JavaScript programs have grown from a few lines to several hundred kilobytes of source code. While JavaScript is very efficient in doing the things it was designed to do, performance has become a limiting factor to further development of web-based JavaScript applications.
-
-V8 is a new JavaScript engine specifically designed for fast execution of large JavaScript applications. If your web application is bound by JavaScript execution speed, using V8 instead of your current JavaScript engine is likely to improve your application's performance. How big the improvement is depends on how much JavaScript is executed and the nature of that JavaScript. For example, if the functions in your application tend to be run again and again, the performance improvement will be greater than if many different functions tend to run only once. The reason for this will become clearer as you read the rest of this document.
-
-There are three key areas to V8's performance:
-
-- [Fast Property Access](#fast-property-access)
-- [Dynamic Machine Code Generation](#dynamic-machine-code-generation)
-- [Efficient Garbage Collection](#efficient-garbage-collection)
-
-# Fast Property Access
-
-JavaScript is a dynamic programming language: properties can be added to, and deleted from, objects on the fly. This means an object's properties are likely to change. Most JavaScript engines use a dictionary-like data structure as storage for object properties - each property access requires a dynamic lookup to resolve the property's location in memory. This approach makes accessing properties in JavaScript typically much slower than accessing instance variables in programming languages like Java and Smalltalk. In these languages, instance variables are located at fixed offsets determined by the compiler due to the fixed object layout defined by the object's class. Access is simply a matter of a memory load or store, often requiring only a single instruction.
-
-To reduce the time required to access JavaScript properties, V8 does not use dynamic lookup to access properties. Instead, V8 dynamically creates hidden classes behind the scenes. This basic idea is not new - the prototype-based programming language Self used maps to do something similar. (See for example, [An Efficient Implementation of Self, a Dynamically-Typed Object-Oriented Language Based on Prototypes](http://research.sun.com/self/papers/implementation.html)). In V8, an object changes its hidden class when a new property is added.
-
-To clarify this, imagine a simple JavaScript function as follows:
-
-```js
-function Point(x, y) {
- this.x = x;
- this.y = y;
-}
-```
-
-When `new Point(x, y)` is executed a new `Point` object is created. When V8 does this for the first time, V8 creates an initial hidden class of `Point`, called `C0` in this example. As the object does not yet have any properties defined the initial class is empty. At this stage the `Point` object's hidden class is `C0`.
-
-
-
-Executing the first statement in `Point` (`this.x = x;`) creates a new property, `x`, in the `Point` object. In this case, V8:
-
-creates another hidden class `C1`, based on `C0`, then adds information to `C1` that describes the object as having one property, `x`, the value of which is stored at offset `0` (zero) in the `Point` object.
-updates `C0` with a class transition indicating that if a property `x` is added to an object described by `C0` then the hidden class `C1` should be used instead of `C0`. At this stage the `Point` object's hidden class is `C1`.
-
-
-
-Executing the second statement in `Point` (`this.y = y;`) creates a new property, `y`, in the `Point` object. In this case, V8:
-
-- creates another hidden class `C2`, based on `C1`, then adds information to `C2` that describes the object as also having property `y` stored at offset `1` (one) in the `Point` object.
-- updates `C1` with a class transition indicating that if a property `y` is added to an object described by `C1` then the hidden class `C2` should be used instead of `C1`. At this stage the `Point` object's hidden class is `C2`.
-
-
-
-It might seem inefficient to create a new hidden class whenever a property is added. However, because of the class transitions the hidden classes can be reused. The next time a new `Point` is created no new hidden classes are created, instead the new `Point` object shares the classes with the first `Point` object. For example, if another `Point` object is created:
-
-- initially the `Point` object has no properties so the newly created object refers to the initial class `C0`.
-- when property `x` is added, V8 follows the hidden class transition from `C0` to `C1` and writes the value of `x` at the offset specified by `C1`.
-- when property `y` is added, V8 follows the hidden class transition from `C1` to `C2` and writes the value of `y` at the offset specified by `C2`.
-
-Even though JavaScript is more dynamic than most object oriented languages, the runtime behavior of most JavaScript programs results in a high degree of structure-sharing using the above approach. There are two advantages to using hidden classes: property access does not require a dictionary lookup, and they enable V8 to use the classic class-based optimization, inline caching. For more on inline caching see [Efficient Implementation of the Smalltalk-80 System](http://portal.acm.org/citation.cfm?id=800017.800542).
-
-# Dynamic Machine Code Generation
-
-During initial execution of the code for accessing a property of a given object, V8 determines the object's current hidden class. V8 optimizes property access by predicting that this class will also be used for all future objects accessed in the same section of code and uses the information in the class to patch the inline cache code to use the hidden class. If V8 has predicted correctly the property's value is assigned (or fetched) in a single operation. If the prediction is incorrect, V8 patches the code to remove the optimisation.
-
-For example, the JavaScript code to access property `x` from a `Point` object is:
-```js
-point.x
-```
-
-In V8, the machine code generated for accessing `x` is:
-
-```Assembly
-# ebx = the point object
-cmp [ebx,<hidden class offset>],<cached hidden class>
-jne <inline cache miss>
-mov eax,[ebx, <cached x offset>]
-```
-
-If the object's hidden class does not match the cached hidden class, execution jumps to the V8 runtime system that handles inline cache misses and patches the inline cache code. If there is a match, which is the common case, the value of the `x` property is simply retrieved.
-
-When there are many objects with the same hidden class the same benefits are obtained as for most static languages. The combination of using hidden classes to access properties with inline caching and machine code generation optimises for cases where the same type of object is frequently created and accessed in a similar way. This greatly improves the speed at which most JavaScript code can be executed.
-
-# Efficient Garbage Collection
-
-V8 reclaims memory used by objects that are no longer required in a process known as garbage collection. To ensure fast object allocation, short garbage collection pauses, and no memory fragmentation V8 employs a stop-the-world, generational, accurate, garbage collector. This means that V8:
-
-- stops program execution when performing a garbage collection cycle.
-- processes only part of the object heap in most garbage collection cycles. This minimizes the impact of stopping the application.
-- always knows exactly where all objects and pointers are in memory. This avoids falsely identifying objects as pointers which can result in memory leaks.
-
-In V8, the object heap is segmented into two parts: new space where objects are created, and old space to which objects surviving a garbage collection cycle are promoted. If an object is moved in a garbage collection cycle, V8 updates all pointers to the object.
\ No newline at end of file
+# This content has moved to <https://v8.dev/>.
diff --git "a/Embedder\047s-Guide.md" "b/Embedder\047s-Guide.md"
index 91a6b01..12e4181 100644
--- "a/Embedder\047s-Guide.md"
+++ "b/Embedder\047s-Guide.md"
@@ -1,339 +1 @@
-If you've read the [Getting Started](https://github.com/v8/v8/wiki/Getting-Started-with-Embedding) guide you will already be familiar with using V8 as a standalone virtual machine and with some key V8 concepts such as handles, scopes, and contexts. This document discusses these concepts further and introduces others that are key to embedding V8 within your own C++ application.
-
-The V8 API provides functions for compiling and executing scripts, accessing C++ methods and data structures, handling errors, and enabling security checks. Your application can use V8 just like any other C++ library. Your C++ code accesses V8 through the V8 API by including the header `include/v8.h`.
-
-The [V8 Design Elements](https://github.com/v8/v8/wiki/Design-Elements) document provides background you may find useful when optimizing your application for V8.
-
-# Audience
-
-This document is intended for C++ programmers who want to embed the V8 JavaScript engine within a C++ application. It will help you to make your own application's C++ objects and methods available to JavaScript, and to make JavaScript objects and functions available to your C++ application.
-
-# Handles and Garbage Collection
-
-A handle provides a reference to a JavaScript object's location in the heap. The V8 garbage collector reclaims memory used by objects that can no longer again be accessed. During the garbage collection process the garbage collector often moves objects to different locations in the heap. When the garbage collector moves an object the garbage collector also updates all handles that refer to the object with the object's new location.
-
-An object is considered garbage if it is inaccessible from JavaScript and there are no handles that refer to it. From time to time the garbage collector removes all objects considered to be garbage. V8's garbage collection mechanism is key to V8's performance. To learn more about it see [V8 Design Elements](https://github.com/v8/v8/wiki/Design-Elements).
-
-There are several types of handles:
-
-- Local handles are held on a stack and are deleted when the appropriate destructor is called. These handles' lifetime is determined by a handle scope, which is often created at the beginning of a function call. When the handle scope is deleted, the garbage collector is free to deallocate those objects previously referenced by handles in the handle scope, provided they are no longer accessible from JavaScript or other handles. This type of handle is used in the example in [Getting Started](Getting Started with Embedding).
-
- Local handles have the class `Local<SomeType>`.
-
- > Note: The handle stack is not part of the C++ call stack, but the handle scopes are embedded in the C++ stack. Handle scopes can only be stack-allocated, not allocated with new.
-
-- Persistent handles provide a reference to a heap-allocated JavaScript Object, just like a local handle. There are two flavors, which differ in the lifetime management of the reference they handle. Use a persistent handle when you need to keep a reference to an object for more than one function call, or when handle lifetimes do not correspond to C++ scopes. Google Chrome, for example, uses persistent handles to refer to Document Object Model (DOM) nodes. A persistent handle can be made weak, using `PersistentBase::SetWeak`, to trigger a callback from the garbage collector when the only references to an object are from weak persistent handles.
- - A `UniquePersistent<SomeType>` handle relies on C++ constructors and destructors to manage the lifetime of the underlying object.
- - A `Persistent<SomeType>` can be constructed with its constructor, but must be explicitly cleared with `Persistent::Reset`.
-
-- There are other types of handles which are rarely used, that we will only briefly mention here
- - `Eternal` is a persistent handle for JavaScript objects that are expected to never be deleted. It is cheaper to use because it relieves the garbage collector from determining the liveness of that object.
- - Both Persistent and UniquePersistent cannot be copied, which makes them unsuitable as values with pre-C++11 standard library containers. `PersistentValueMap` and `PersistentValueVector` provide container classes for persistent values, with map and vector-like semantics. C++11 embedders do not require these, since C++11 move semantics solve the underlying problem.
-
-Of course, creating a local handle every time you create an object can result in a lot of handles! This is where handle scopes are very useful. You can think of a handle scope as a container that holds lots of handles. When the handle scope's destructor is called all handles created within that scope are removed from the stack. As you would expect, this results in the objects to which the handles point being eligible for deletion from the heap by the garbage collector.
-
-Returning to our very simple example, described in [Getting Started](Getting Started with Embedding), in the following diagram you can see the handle-stack and heap-allocated objects. Note that `Context::New()` returns a Local handle, and we create a new Persistent handle based on it to demonstrate the usage of Persistent handles.
-
-
-
-When the destructor, `HandleScope::~HandleScope`, is called the handle scope is deleted. Objects referred to by handles within the deleted handle scope are eligible for removal in the next garbage collection if there are no other references to them. The garbage collector can also remove the `source_obj`, and `script_obj` objects from the heap as they are no longer referenced by any handles or otherwise reachable from JavaScript. Since the context handle is a persistent handle, it is not removed when the handle scope is exited. The only way to remove the context handle is to explicitly call `Reset` on it.
-
-> Note: Throughout this document the term handle refers to a local handle, when discussing a persistent handle that term is used in full.
-
-It is important to be aware of one common pitfall with this model: *you cannot return a local handle directly from a function that declares a handle scope*. If you do the local handle you're trying to return will end up being deleted by the handle scope's destructor immediately before the function returns. The proper way to return a local handle is construct an `EscapableHandleScope` instead of a `HandleScope` and to call the `Escape` method on the handle scope, passing in the handle whose value you want to return. Here's an example of how that works in practice:
-
-```c++
-// This function returns a new array with three elements, x, y, and z.
-Local<Array> NewPointArray(int x, int y, int z) {
- v8::Isolate* isolate = v8::Isolate::GetCurrent();
-
- // We will be creating temporary handles so we use a handle scope.
- EscapableHandleScope handle_scope(isolate);
-
- // Create a new empty array.
- Local<Array> array = Array::New(isolate, 3);
-
- // Return an empty result if there was an error creating the array.
- if (array.IsEmpty())
- return Local<Array>();
-
- // Fill out the values
- array->Set(0, Integer::New(isolate, x));
- array->Set(1, Integer::New(isolate, y));
- array->Set(2, Integer::New(isolate, z));
-
- // Return the value through Escape.
- return handle_scope.Escape(array);
-}
-```
-
-The `Escape` method copies the value of its argument into the enclosing scope, deletes all its local handles, and then gives back the new handle copy which can safely be returned.
-
-# Contexts
-
-In V8, a context is an execution environment that allows separate, unrelated, JavaScript applications to run in a single instance of V8. You must explicitly specify the context in which you want any JavaScript code to be run.
-
-Why is this necessary? Because JavaScript provides a set of built-in utility functions and objects that can be changed by JavaScript code. For example, if two entirely unrelated JavaScript functions both changed the global object in the same way then unexpected results are fairly likely to happen.
-
-In terms of CPU time and memory, it might seem an expensive operation to create a new execution context given the number of built-in objects that must be built. However, V8's extensive caching ensures that, while the first context you create is somewhat expensive, subsequent contexts are much cheaper. This is because the first context needs to create the built-in objects and parse the built-in JavaScript code while subsequent contexts only have to create the built-in objects for their context. With the V8 snapshot feature (activated with build option `snapshot=yes`, which is the default) the time spent creating the first context will be highly optimized as a snapshot includes a serialized heap which contains already compiled code for the built-in JavaScript code. Along with garbage collection, V8's extensive caching is also key to V8's performance, for more information see [V8 Design Elements](https://github.com/v8/v8/wiki/Design-Elements).
-
-When you have created a context you can enter and exit it any number of times. While you are in context A you can also enter a different context, B, which means that you replace A as the current context with B. When you exit B then A is restored as the current context. This is illustrated below:
-
-
-
-Note that the built-in utility functions and objects of each context are kept separate. You can optionally set a security token when you create a context. See the [Security Model](#security-model) section for more information.
-
-The motivation for using contexts in V8 was so that each window and iframe in a browser can have its own fresh JavaScript environment.
-
-# Templates
-
-A template is a blueprint for JavaScript functions and objects in a context. You can use a template to wrap C++ functions and data structures within JavaScript objects so that they can be manipulated by JavaScript scripts. For example, Google Chrome uses templates to wrap C++ DOM nodes as JavaScript objects and to install functions in the global namespace. You can create a set of templates and then use the same ones for every new context you make. You can have as many templates as you require. However you can only have one instance of any template in any given context.
-
-In JavaScript there is a strong duality between functions and objects. To create a new type of object in Java or C++ you would typically define a new class. In JavaScript you create a new function instead, and create instances using the function as a constructor. The layout and functionality of a JavaScript object is closely tied to the function that constructed it. This is reflected in the way V8 templates work. There are two types of templates:
-
-- Function templates
-
- A function template is the blueprint for a single function. You create a JavaScript instance of the template by calling the template's `GetFunction` method from within the context in which you wish to instantiate the JavaScript function. You can also associate a C++ callback with a function template which is called when the JavaScript function instance is invoked.
-
-- Object templates
-
- Each function template has an associated object template. This is used to configure objects created with this function as their constructor. You can associate two types of C++ callbacks with object templates:
- - accessor callbacks are invoked when a specific object property is accessed by a script
- - interceptor callbacks are invoked when any object property is accessed by a script
- [Accessors](#accessors) and [interceptors](#interceptors) are discussed later in this document.
-
-The following code provides an example of creating a template for the global object and setting the built-in global functions.
-
-```c++
-// Create a template for the global object and set the
-// built-in global functions.
-Local<ObjectTemplate> global = ObjectTemplate::New(isolate);
-global->Set(String::NewFromUtf8(isolate, "log"), FunctionTemplate::New(isolate, LogCallback));
-
-// Each processor gets its own context so different processors
-// do not affect each other.
-Persistent<Context> context = Context::New(isolate, NULL, global);
-```
-
-This example code is taken from `JsHttpProcessor::Initializer` in the `process.cc` sample.
-
-# Accessors
-
-An accessor is a C++ callback that calculates and returns a value when an object property is accessed by a JavaScript script. Accessors are configured through an object template, using the `SetAccessor` method. This method takes the name of the property with which it is associated and two callbacks to run when a script attempts to read or write the property.
-
-The complexity of an accessor depends upon the type of data you are manipulating:
-
-- [Accessing Static Global Variables](#accessing-static-global-variables)
-- [Accessing Dynamic Variables](#accessing-dynamic-variables)
-
-## Accessing Static Global Variables
-
-Let's say there are two C++ integer variables, `x` and `y` that are to be made available to JavaScript as global variables within a context. To do this, you need to call C++ accessor functions whenever a script reads or writes those variables. These accessor functions convert a C++ integer to a JavaScript integer using `Integer::New`, and convert a JavaScript integer to a C++ integer using `Int32Value`. An example is provided below:
-
-```c++
-void XGetter(Local<String> property,
- const PropertyCallbackInfo<Value>& info) {
- info.GetReturnValue().Set(x);
-}
-
-void XSetter(Local<String> property, Local<Value> value,
- const PropertyCallbackInfo<void>& info) {
- x = value->Int32Value();
-}
-
-// YGetter/YSetter are so similar they are omitted for brevity
-
-Local<ObjectTemplate> global_templ = ObjectTemplate::New(isolate);
-global_templ->SetAccessor(String::NewFromUtf8(isolate, "x"), XGetter, XSetter);
-global_templ->SetAccessor(String::NewFromUtf8(isolate, "y"), YGetter, YSetter);
-Persistent<Context> context = Context::New(isolate, NULL, global_templ);
-```
-
-Note that the object template in the code above is created at the same time as the context. The template could have been created in advance and then used for any number of contexts.
-
-## Accessing Dynamic Variables
-
-In the preceding example the variables were static and global. What if the data being manipulated is dynamic, as is true of the DOM tree in a browser? Let's imagine `x` and `y` are object fields on the C++ class `Point`:
-
-```c++
-class Point {
- public:
- Point(int x, int y) : x_(x), y_(y) { }
- int x_, y_;
-}
-```
-
-To make any number of C++ `point` instances available to JavaScript we need to create one JavaScript object for each C++ `point` and make a connection between the JavaScript object and the C++ instance. This is done with external values and internal object fields.
-
-First create an object template for the `point` wrapper object:
-
-```c++
-Local<ObjectTemplate> point_templ = ObjectTemplate::New(isolate);
-```
-
-Each JavaScript `point` object keeps a reference to the C++ object for which it is a wrapper with an internal field. These fields are so named because they cannot be accessed from within JavaScript, they can only be accessed from C++ code. An object can have any number of internal fields, the number of internal fields is set on the object template as follows:
-
-```
-point_templ->SetInternalFieldCount(1);
-```
-
-Here the internal field count is set to `1` which means the object has one internal field, with an index of `0`, that points to a C++ object.
-
-Add the `x` and `y` accessors to the template:
-
-```c++
-point_templ->SetAccessor(String::NewFromUtf8(isolate, "x"), GetPointX, SetPointX);
-point_templ->SetAccessor(String::NewFromUtf8(isolate, "y"), GetPointY, SetPointY);
-```
-
-Next, wrap a C++ point by creating a new instance of the template and then setting the internal field `0` to an external wrapper around the point `p`.
-
-```c++
-Point* p = ...;
-Local<Object> obj = point_templ->NewInstance();
-obj->SetInternalField(0, External::New(isolate, p));
-```
-
-The external object is simply a wrapper around a `void*`. External objects can only be used to store reference values in internal fields. JavaScript objects can not have references to C++ objects directly so the external value is used as a "bridge" to go from JavaScript into C++. In that sense external values are the opposite of handles since handles lets C++ make references to JavaScript objects.
-
-Here's the definition of the `get` and `set` accessors for `x`, the `y` accessor definitions are identical except `y` replaces `x`:
-
-```c++
-void GetPointX(Local<String> property,
- const PropertyCallbackInfo<Value>& info) {
- Local<Object> self = info.Holder();
- Local<External> wrap = Local<External>::Cast(self->GetInternalField(0));
- void* ptr = wrap->Value();
- int value = static_cast<Point*>(ptr)->x_;
- info.GetReturnValue().Set(value);
-}
-
-void SetPointX(Local<String> property, Local<Value> value,
- const PropertyCallbackInfo<void>& info) {
- Local<Object> self = info.Holder();
- Local<External> wrap = Local<External>::Cast(self->GetInternalField(0));
- void* ptr = wrap->Value();
- static_cast<Point*>(ptr)->x_ = value->Int32Value();
-}
-```
-
-Accessors extract the reference to the `point` object that was wrapped by the JavaScript object and then read and writes the associated field. This way these generic accessors can be used on any number of wrapped point objects.
-
-# Interceptors
-
-You can also specify a callback for whenever a script accesses any object property. These are called interceptors. For efficiency, there are two types of interceptors:
-
-- *named property interceptors* - called when accessing properties with string names.
- An example of this, in a browser environment, is `document.theFormName.elementName`.
-- *indexed property interceptors* - called when accessing indexed properties. An example of this, in a browser environment, is `document.forms.elements[0]`.
-
-The sample `process.cc`, provided with the V8 source code, includes an example of using interceptors. In the following code snippet `SetNamedPropertyHandler` specifies the `MapGet` and `MapSet` interceptors:
-
-```c++
-Local<ObjectTemplate> result = ObjectTemplate::New(isolate);
-result->SetNamedPropertyHandler(MapGet, MapSet);
-```
-
-The `MapGet` interceptor is provided below:
-
-```c++
-void JsHttpRequestProcessor::MapGet(Local<String> name,
- const PropertyCallbackInfo<Value>& info) {
- // Fetch the map wrapped by this object.
- map<string, string> *obj = UnwrapMap(info.Holder());
-
- // Convert the JavaScript string to a std::string.
- string key = ObjectToString(name);
-
- // Look up the value if it exists using the standard STL idiom.
- map<string, string>::iterator iter = obj->find(key);
-
- // If the key is not present return an empty handle as signal.
- if (iter == obj->end()) return;
-
- // Otherwise fetch the value and wrap it in a JavaScript string.
- const string &value = (*iter).second;
- info.GetReturnValue().Set(String::NewFromUtf8(value.c_str(), String::kNormalString, value.length()));
-}
-```
-
-As with accessors, the specified callbacks are invoked whenever a property is accessed. The difference between accessors and interceptors is that interceptors handle all properties, while accessors are associated with one specific property.
-
-# Security Model
-
-The "same origin policy" (first introduced with Netscape Navigator 2.0) prevents a document or script loaded from one "origin" from getting or setting properties of a document from a different "origin". The term origin is defined here as a combination of domain name (www.example.com), protocol (http or https) and port (for example, www.example.com:81 is not the same as www.example.com). All three must match for two webpages to be considered to have the same origin. Without this protection, a malicious web page could compromise the integrity of another web page.
-
-In V8 an "origin" is defined as a context. Access to any context other than the one from which you are calling is not allowed by default. To access a context other than the one from which you are calling, you need to use security tokens or security callbacks. A security token can be any value but is typically a symbol, a canonical string that does not exist anywhere else. You can optionally specify a security token with `SetSecurityToken` when you set up a context. If you do not specify a security token V8 will automatically generate one for the context you are creating.
-
-When an attempt is made to access a global variable the V8 security system first checks the security token of the global object being accessed against the security token of the code attempting to access the global object. If the tokens match access is granted. If the tokens do not match V8 performs a callback to check if access should be allowed. You can specify whether access to an object should be allowed by setting the security callback on the object, using the SetAccessCheckCallbacks method on object templates. The V8 security system can then fetch the security callback of the object being accessed and call it to ask if another context is allowed to access it. This callback is given the object being accessed, the name of the property being accessed, the type of access (read, write, or delete for example) and returns whether or not to allow access.
-
-This mechanism is implemented in Google Chrome so that if security tokens do not match, a special callback is used to allow access only to the following: `window.focus()`, `window.blur()`, `window.close()`, `window.location`, `window.open()`, `history.forward()`, `history.back()`, and `history.go()`.
-
-# Exceptions
-
-V8 will throw an exception if an error occurs - for example, when a script or function attempts to read a property that does not exist, or if a function is called that is not a function.
-
-V8 returns an empty handle if an operation did not succeed. It is therefore important that your code checks a return value is not an empty handle before continuing execution. Check for an empty handle with the `Local` class's public member function `IsEmpty()`.
-
-You can catch exceptions with `TryCatch`, for example:
-
-```c++
-TryCatch trycatch(isolate);
-Local<Value> v = script->Run();
-if (v.IsEmpty()) {
- Local<Value> exception = trycatch.Exception();
- String::Utf8Value exception_str(exception);
- printf("Exception: %s\n", *exception_str);
- // ...
-}
-```
-
-If the value returned is an empty handle, and you do not have a `TryCatch` in place, your code must bail out. If you do have a `TryCatch` the exception is caught and your code is allowed to continue processing.
-
-# Inheritance
-
-JavaScript is a *class-free*, object-oriented language, and as such, it uses prototypal inheritance instead of classical inheritance. This can be puzzling to programmers trained in conventional object-oriented languages like C++ and Java.
-
-Class-based object-oriented languages, such as Java and C++, are founded on the concept of two distinct entities: classes and instances. JavaScript is a prototype-based language and so does not make this distinction: it simply has objects. JavaScript does not natively support the declaration of class hierarchies; however, JavaScript's prototype mechanism simplifies the process of adding custom properties and methods to all instances of an object. In JavaScript, you can add custom properties to objects. For example:
-
-```js
-// Create an object "bicycle"
-function bicycle(){
-}
-// Create an instance of bicycle called roadbike
-var roadbike = new bicycle()
-// Define a custom property, wheels, on roadbike
-roadbike.wheels = 2
-```
-
-A custom property added this way only exists for that instance of the object. If we create another instance of `bicycle()`, called `mountainbike` for example, `mountainbike.wheels` would return `undefined` unless the `wheels` property is explicitly added.
-
-Sometimes this is exactly what is required, at other times it would be helpful to add the custom property to all instances of an object - all bicycles have wheels after all. This is where the prototype object of JavaScript is very useful. To use the prototype object, reference the keyword `prototype` on the object before adding the custom property to it as follows:
-
-```js
-// First, create the "bicycle" object
-function bicycle(){
-}
-// Assign the wheels property to the object's prototype
-bicycle.prototype.wheels = 2
-```
-
-All instances of `bicycle()` will now have the `wheels` property prebuilt into them.
-
-The same approach is used in V8 with templates. Each `FunctionTemplate` has a `PrototypeTemplate` method which gives a template for the function's prototype. You can set properties, and associate C++ functions with those properties, on a `PrototypeTemplate` which will then be present on all instances of the corresponding `FunctionTemplate`. For example:
-
-```c++
-Local<FunctionTemplate> biketemplate = FunctionTemplate::New(isolate);
-biketemplate->PrototypeTemplate().Set(
- String::NewFromUtf8(isolate, "wheels"),
- FunctionTemplate::New(isolate, MyWheelsMethodCallback)->GetFunction();
-)
-```
-
-This causes all instances of `biketemplate` to have a `wheels` method in their prototype chain which, when called, causes the C++ function `MyWheelsMethodCallback` to be called.
-
-V8's `FunctionTemplate` class provides the public member function `Inherit()` which you can call when you want a function template to inherit from another function template, as follows:
-
-```c++
-void Inherit(Local<FunctionTemplate> parent);
-```
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/embed>.
diff --git a/Evaluating-Code-Coverage.md b/Evaluating-Code-Coverage.md
index 0a84ab3..6f4635f 100644
--- a/Evaluating-Code-Coverage.md
+++ b/Evaluating-Code-Coverage.md
@@ -1,27 +1 @@
-You are working on a change. You want to evaluate code coverage for your new code.
-
-V8 provides 2 tools for doing this - local, on your machine; and build infrastructure support.
-
-# Local
-
-Relative to the root of the v8 repo, use `./tools/gcov.sh` (tested on linux). This will use gnu's code coverage tooling and some scripting to produce a html report, where you can drill down coverage info per directory, file, and then down to line of code.
-
-The script will build v8 under a separate out directory, using gcov settings. We use a separate directory to avoid clobbering your normal build settings. This separate directory is called `cov` - it is created immediately under the repo root. `gcov.sh` will then run the test suite, and produce the report. The path to the report is provided when the script completes.
-
-If your change has architecture specific components, you can cumulatively collect coverage from architecture specific runs.
-
-`./tools/gcov.sh x64 arm`
-
-This will in-place rebuild for each architecture, clobbering the binaries from the previous run, but preserving and accumulating over the coverage results.
-
-By default, the script collects from Release runs. If you want Debug, you may specify so:
-
-`BUILD_TYPE=Debug ./tools/gcov.sh x64 arm arm64`
-
-Running the script with no options will provide a summary of options as well.
-
-# Code Coverage Bot
-
-For each change that landed, we run a x64 coverage analysis - see the [coverage bot](https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20gcov%20coverage). We don't run bots for coverage for other architectures.
-
-To get the report for a particular run, you want to list the build steps, find the "gsutil coverage report" one (towards the end), and open the "report" under it.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/evaluate-code-coverage>.
diff --git a/Example-code.md b/Example-code.md
index e69a1bb..12e4181 100644
--- a/Example-code.md
+++ b/Example-code.md
@@ -1,6 +1 @@
-The following samples are provided as part of the source code download:
-
-# process.cc
-This sample provides the code necessary to extend a hypothetical HTTP request processing application - which could be part of a web server, for example - so that it is scriptable. It takes a JavaScript script as an argument, which must provide a function called Process. The JavaScript Process function can be used to, for example, collect information such as how many hits each page served by the fictional web server gets.
-# shell.cc
-This sample takes filenames as arguments then reads and executes their contents. Includes a command prompt at which you can enter JavaScript code snippets which are then executed. In this sample additional functions like print are also added to JavaScript through the use of object and function templates.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/embed>.
diff --git a/Feature-launch-process.md b/Feature-launch-process.md
index b0d408f..09c555e 100644
--- a/Feature-launch-process.md
+++ b/Feature-launch-process.md
@@ -1,76 +1 @@
-The V8 project aims to develop a high-performance, standards-compliant ECMAScript/JavaScript implementation. This document outlines our guidelines for “language-facing” changes and the process through which they are enforced.
-
-# Guidelines
-
-We strive to be responsible stewards of JavaScript language, balancing interoperability and innovation. Our guidelines align closely with those of [Blink project](https://www.chromium.org/blink#new-features). Keep in mind that these are directional beacons, not bright-line rules.
-
-## Compatibility risk
-
-Factors that reduce compatibility risk include:
-- **Acceptance at TC39 committee**. TC39 is a primary steward of JavaScript language. We track progress of language features through [the TC39 process](https://tc39.github.io/process-document/) and consider features that reach higher stages more stable and ready for implementation. The V8 team is actively involved in the TC39 committee and champions new features when appropriate.
-- **Interest from other browser vendors**. Implementations in other browsers are a clear signal of feature usefulness. In order of strength, this includes:
- 1. compatible implementation in more than one engine
- 2. compatible implementation in one engine
- 3. implementation in one or more engines under an experimental flag
- 4. other vendors expressed interest in the feature
-
-## Impact on Web Platform
-
-In prioritizing the work of implementing new features, we will prefer those which unblock significant new **capability**, **performance** or **expressiveness**.
-
-For every change we implement we want to validate our design and implementation every step of the way. As such, we aim to have a **robust set of use cases** for new features we implement; ideally, we want to be involved with the community, identifying **groups of developers ready and willing to provide feedback** for our implementations.
-
-## Technical considerations
-
-From day one, V8 has been all about performance. We strive to set standards for JavaScript performance across browsers, both by implementing advanced optimizations and by building robust benchmarks in our [Octane benchmarking suite](http://chromium.github.io/octane/).
-
-From a compatibility risk perspective, bugs and inadvertent incompatibilities in language implementations are very painful for users. Therefore we take special care to ensure high-quality implementations of JavaScript features we ship.
-
-With this in mind, we expect all JavaScript changes implemented in V8 to be accompanied by:
-
-1. **Assessment of the impact on the codebase**. V8 is a highly complex and tightly knit codebase with many interdependencies; support cost for particularly pervasive features might be substantial.
-2. **Conformance tests**, ideally suitable for future inclusion in [ECMA-262 test suite](https://github.com/tc39/test262).
-3. **Performance tests**.
-
-As the implementation of a particular feature progresses, we expect both conformance and performance test suites to progress in parallel.
-
-# Process
-
-Language features implemented in V8 go over three stages: experimental implementation, staging, and shipping without a flag.
-
-## Experimental implementation
-
-Anyone who wants to implement a feature in V8 must contact [v8-users@googlegroups.com](v8-users@googlegroups.com) with an “intent to implement” email. Then follow these steps:
-
-- Clarify the feature status with regard to the criteria in the guidelines on this page (TC39 acceptance, interest from browser vendors, testing plans) in an “intent to implement” email.
-- Provide a design doc to clarify V8 code base impact.
-- The implementation should also consider DevTools support. Refer to the [_debugger support checklist for new language features_](https://docs.google.com/document/d/1_DBgJ9eowJJwZYtY6HdiyrizzWzwXVkG5Kt8s3TccYE/edit?usp=sharing) for more details.
-- Implement the feature under a `--harmony-X` flag.
-- Develop conformance and performance tests in parallel.
-
-## Staging
-
-At this stage, the feature becomes available in V8 under the `--es-staging` flag. The criteria for moving a feature to that stage are:
-
-- The specification of the feature is stable
- - One example of feature stability indicator is it being advanced to stage 3 of [the TC39 process](https://tc39.github.io/process-document/)
-- Implementation is mostly complete; remaining issues are identified and documented
-- Conformance tests are in place
-- Performance regression tests are in place
-
-## Turning the flag on — shipping the feature to the open Web
-
-As the implementation of a feature progresses, we evaluate community feedback on feature design and implementation. The V8 team makes a decision to turn the feature on by default based on the community opinion of the feature and the technical maturity of the implementation.
-
-Some community signals we consider before shipping:
-
-- **The feature is on the clear track to standardization at TC39**. For example, a feature spec is available and has been through several rounds of reviews, or a feature is at Stage 3+ of the TC39 process.
-- **There is a clear interest in the feature from other browser vendors.** For example, another engine is shipping a compatible implementation in an experimental or stable channel.
-
-The following technical criteria must be met for shipping:
-
-1. The implementation is complete; any feedback received from the staged implementation is addressed.
-2. No technical debt: the V8 team is satisfied with the feature’s implementation quality (including basic DevTools support).
-3. **Performance** is consistent with our high-performance goals.
-
-Before landing the CL that enables the flag by default, an “intent to ship” email is sent to to [v8-users@googlegroups.com](https://groups.google.com/d/forum/v8-users) and [blink-dev@chromium.org](https://groups.google.com/a/chromium.org/d/forum/blink-dev). For V8/JS features, this email is just an FYI to blink-dev; it doesn’t need sign-off from Blink API owners.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/feature-launch-process>.
diff --git a/Flake-bisect.md b/Flake-bisect.md
index 9799e90..8c43474 100644
--- a/Flake-bisect.md
+++ b/Flake-bisect.md
@@ -1,49 +1 @@
-Flaky tests are reported in a separate step on the bots ([example build](https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20-%20verify%20csa/9271)).
-
-Each test log provides a pre-filled command line for triggering an automated flake bisect, like:
-`Trigger flake bisect on command line:`
-`echo '{"bisect_buildername": "V8 Linux64 - verify csa", "bisect_mastername": "client.v8", "build_config": "Release", "extra_args": [], "isolated_name": "bot_default", "swarming_dimensions": ["cpu:x86-64", "gpu:none", "os:Ubuntu-14.04", "pool:Chrome"], "test_name": "inspector/runtime/command-line-api-without-side-effects", "timeout_sec": 60, "to_revision": "7f51fdac5bc8bf28b30904e1601819b356187b43", "total_timeout_sec": 120, "variant": "nooptimization"}' | buildbucket.py put -b luci.v8.try -n v8_flako -p -`
-
-Before triggering flake bisects for the first time, users must log in with a google.com account:
-`depot-tools-auth login https://cr-buildbucket.appspot.com`
-
-Then execute the provided command line, which returns a build URL running flake bisect ([example](https://ci.chromium.org/p/v8/builders/luci.v8.try/v8_flako/b8935497223724984544)).
-
-If you're in luck, bisection will point you to a suspect. If not, you might want to read further...
-
-# Detailed description
-For technical details, see also the implementation [tracker bug](https://crbug.com/711249). The flake bisect approach has the same intentions as [findit](https://sites.google.com/chromium.org/cat/findit), but uses a different implementation.
-
-## How does it work?
-A bisect job has 3 phases: calibration, backwards and inwards bisection. During calibration, testing is repeated doubling the total timeout (or the number of repetitions) until enough flakes are detected in one run. Then, backwards bisection doubles the git range until a revision without flakes is found. At last, we bisect into the range of the good revision and the oldest bad one. Note, bisection doesn't produce new build products, it is purely based on builds previously created on V8's continuous infrastructure.
-
-## Bisection fails when...
-* No confidence can be reached during calibration. This is typical for one-in-a-million flakes or flaky behavior only visible when other tests run in parallel (e.g. memory hungry tests).
-* The culprit is too old. Bisection bails out after a certain number of steps, or if older builds are not available anymore on the isolate server.
-* The overall bisect job times out. In this case it might be possible to restart it with an older known bad revision.
-
-## Properties for customizing flake bisect
-* extra_args: Extra arguments passed to V8's run-tests.py script.
-* repetitions: Initial number of test repetitions (passed to run-tests.py's --random-seed-stress-count option; unused if total_timeout_sec is used).
-* timeout_sec: Timeout parameter passed to run-tests.py.
-* to_revision: Revision known to be bad. This is where bisection will start.
-* total_timeout_sec: Initial total timeout for one entire bisect step. During calibration, this time is doubled several times if needed. Set to 0 to disable and use the 'repetitions' property instead.
-* variant: Name of the testing variant passed to run-tests.py.
-
-## Properties you won't need to change
-* bisect_buildername: Master name of the builder that produced the builds for bisection.
-* bisect_mastername: Name of the builder that produced the builds for bisection.
-* build_config: Build config passed to V8's run-tests.py script (there the parameter name is `--mode`, example: `Release` or `Debug`).
-* isolated_name: Name of the isolated file (e.g. bot_default, mjsunit).
-* swarming_dimensions: Swarming dimensions classifying the type of bot the tests should run on. Passed as list of strings, each in the format name:value.
-* test_name: Fully qualified test name passed to run-tests.py. E.g. `mjsunit/foobar`.
-
-## Tips and tricks
-### Bisecting a hanging test (e.g. dead lock)
-If a failing run times out, while a pass is running very fast, it is useful to tweak the timeout_sec parameter, so that bisection is not delayed waiting for the hanging runs to time out. E.g. if the pass is usually reached in <1 second, set the timeout to something small, e.g. 5 seconds.
-### Getting more confidence on a suspect
-In some runs, confidence is very low. E.g. calibration is satisfied if four flakes are seen in one run. During bisection, every run with one or more flakes is counted as bad. In such cases it might be useful to restart the bisect job setting to_revision to the culprit and using a higher number of repetitions or total timeout than the original job and confirm that the same conclusion is reached again.
-### Working around known timeout issues on windows ([crbug.com/v8/8170](https://crbug.com/v8/8170))
-Sometimes the overall timeout option doesn't work on windows. In this case it's best to estimate a fitting number of repetitions and set total_timeout_sec to 0.
-### Test behavior depending on random seed
-Rarely, a code path is only triggered with a particular random seed. In this case it might be beneficial to fix it using extra_args, e.g. `"extra_args": ["--random-seed=123"]`. Otherwise, the stress runner will use different random seeds throughout. Note though that a particular random seed might reproduce a problem in one revision, but not in another.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/flake-bisect>.
diff --git a/GDB-JIT-Interface.md b/GDB-JIT-Interface.md
index 7fcea82..29da6e7 100644
--- a/GDB-JIT-Interface.md
+++ b/GDB-JIT-Interface.md
@@ -1,63 +1 @@
-# Prerequisites
-
- * V8 3.0.9 or newer
- * GDB 7.0 or newer
- * Linux OS
- * CPU with Intel-compatible architecture (ia32 or x64)
-
-# Introduction
-
-GDB JIT interface integration allows V8 to provide GDB with the symbol and debugging information for a native code emitted in runtime.
-
-When GDB JIT interface is disabled a typical backtrace in GDB will contain frames marked with ??. This frames correspond to dynamically generated code:
-
-```
-#8 0x08281674 in v8::internal::Runtime_SetProperty (args=...) at src/runtime.cc:3758
-#9 0xf5cae28e in ?? ()
-#10 0xf5cc3a0a in ?? ()
-#11 0xf5cc38f4 in ?? ()
-#12 0xf5cbef19 in ?? ()
-#13 0xf5cb09a2 in ?? ()
-#14 0x0809e0a5 in v8::internal::Invoke (construct=false, func=..., receiver=..., argc=0, args=0x0,
- has_pending_exception=0xffffd46f) at src/execution.cc:97
-```
-
-However enabling GDB JIT integration allows GDB to produce more informative stack trace:
-
-```
-#6 0x082857fc in v8::internal::Runtime_SetProperty (args=...) at src/runtime.cc:3758
-#7 0xf5cae28e in ?? ()
-#8 0xf5cc3a0a in loop () at test.js:6
-#9 0xf5cc38f4 in test.js () at test.js:13
-#10 0xf5cbef19 in ?? ()
-#11 0xf5cb09a2 in ?? ()
-#12 0x0809e1f9 in v8::internal::Invoke (construct=false, func=..., receiver=..., argc=0, args=0x0,
- has_pending_exception=0xffffd44f) at src/execution.cc:97
-```
-
-Frames still unknown to GDB correspond to native code without source information. See [GDBJITInterface#KnownLimitations](GDBJITInterface#KnownLimitations.md) for more details.
-
-GDB JIT interface is specified in the GDB documentation: http://sourceware.org/gdb/current/onlinedocs/gdb/JIT-Interface.html
-
-# Enabling GDB JIT integration
-
-GDBJIT currently is by default excluded from the compilation and disabled in runtime. To enable it:
-
- 1. Build V8 library with `ENABLE_GDB_JIT_INTERFACE` defined. If you are using scons to build V8 run it with `gdbjit=on`.
- 1. Pass `--gdbjit` flag when starting V8.
-
-To check that you have enabled GDB JIT integration correctly try setting breakpoint on `__jit_debug_register_code`. This function will be invoked to notify GDB about new code objects.
-
-# Known Limitations
-
- * GDB side of JIT Interface currently (as of GDB 7.2) does not handle registration of code objects very effectively. Each next registration takes more time: with 500 registered objects each next registration takes more than 50ms, with 1000 registered code objects - more than 300 ms. This problem was reported to GDB developers (http://sourceware.org/ml/gdb/2011-01/msg00002.html) but currently there is no solution available. To reduce pressure on GDB current implementation of GDB JIT integration operates in two modes: _default_ and _full_ (enabled by `--gdbjit-full` flag). In _default_ mode V8 notifies GDB only about code objects that have source information attached (this usually includes all user scripts). In _full_ - about all generated code objects (stubs, ICs, trampolines).
-
- * On x64 GDB is unable to properly unwind stack without `.eh_frame` section (Issue 1053 (on Google Code))
-
- * GDB is not notified about code deserialized from the snapshot (Issue 1054 (on Google Code))
-
- * Only Linux OS on Intel-compatible CPUs is supported. For different OSes either a different ELF-header should be generated or a completely different object format should be used.
-
- * Enabling GDB JIT interface disables compacting GC. This is done to reduce pressure on GDB as unregistering and registering each moved code object will incur considerable overhead.
-
- * GDB JIT integration provides only _approximate_ source information. It does not provide any information about local variables, function's arguments, stack layout etc. It does not enable stepping through JavaScript code or setting breakpoint on the given line. However one can set a breakpoint on a function by it's name.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/gdb-jit>.
diff --git a/GUI-and-IDE-Access.md b/GUI-and-IDE-Access.md
index a26bb0e..53c4380 100644
--- a/GUI-and-IDE-Access.md
+++ b/GUI-and-IDE-Access.md
@@ -1,68 +1 @@
-* The source code can be browsed online with [Chromium Codesearch](https://cs.chromium.org/chromium/src/v8/).
-* For instructions how to set up Eclipse for V8, see this [document](https://docs.google.com/document/d/1q3JkYNJhib3ni9QvNKIY_uarVxeVDiDi6teE5MbVIGQ/).
-
-This project's Git repository may be accessed using many other client programs and plug-ins. See your client's documentation for more information.
-
-## Visual Studio Code and cquery
-
-VSCode and cquery provide good code navigation capabilities. It offers "go to definition" as well as "find all references" for C++ symbols and works quite well. This section describes how to get a basic setup on a *nix system.
-
-### Install VSCode
-Install VSCode in your preferred way. We will assume that you can run VSCode from the commandline via the command `code`.
-
-### Install cquery
-Clone cquery from [cquery](https://github.com/cquery-project/cquery) in a directory of your choice. We
-use CQUERY_DIR="$HOME/cquery" in this guide.
-
-```
-git clone https://github.com/cquery-project/cquery $CQUERY_DIR
-cd $CQUERY_DIR
-git submodule update --init
-./waf configure build
-```
-
-If anything goes wrong, be sure to check out [cquery's getting started guide](https://github.com/cquery-project/cquery/wiki/Getting-started).
-
-You can use `git pull && git submodule update` to update cquery at a later time (don't forget to rebuild via `./waf configure build`).
-
-### Install and configure cquery-plugin for VSCode
-Install the cquery extension from the marketplace in VSCode. Open VSCode in your v8 checkout
-```
-cd v8
-code .
-```
-Go to settings in VSCode, for example, via shortcut <CTRL+,>.
-Add the following to your workspace configuration, replacing YOURUSERNAME and YOURV8CHECKOUTDIR appropriately.
-```
-"settings": {
- "cquery.launch.command": "/home/YOURUSERNAME/cquery/build/release/bin/cquery",
- "cquery.cacheDirectory": "/home/YOURUSERNAME/YOURV8CHECKOUTDIR/.vscode/cquery_cached_index/",
- "cquery.completion.include.blacklist": [".*/.vscache/.*", "/tmp.*", "build/.*"],
- [...]
-}
-```
-
-### Provide `compile_commands.json` to cquery
-The last step is to generate a compile_commands.json to cquery. This file will contain the specific compiler command lines used to build V8 to cquery. Run the following command in the V8 checkout:
-
-`ninja -C out.gn/x64.release -t compdb cxx cc > compile_commands.json`
-
-This needs to be re-executed from time to time to teach cquery about new source files. In particular, you should always re-run the command after a BUILD.gn was changed.
-
-### Other Useful Settings
-The auto-closing of parenthesis in VisualStudioCode does not work that well. It can be disabled with
-```
-"editor.autoClosingBrackets": false
-```
-in the user settings.
-
-The following exclusion masks help avoid unwanted results when using search (CTRL+SHIFT+F):
-```
- "files.exclude": {
- "**/.vscode": true, // this is a default value
- },
- "search.exclude": {
- "**/out*": true, // this is a default value
- "**/build*": true // this is a default value
- },
-```
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/ide-setup>.
diff --git a/Getting-Started-with-Embedding.md b/Getting-Started-with-Embedding.md
index 0bd43bf..12e4181 100644
--- a/Getting-Started-with-Embedding.md
+++ b/Getting-Started-with-Embedding.md
@@ -1,52 +1 @@
-This document introduces some key V8 concepts and provides a `hello world` example to get you started with V8 code.
-
-## Audience
-
-This document is intended for C++ programmers who want to embed the V8 JavaScript engine within a C++ application.
-
-# Hello World
-
-Let's look at a [Hello World example](https://chromium.googlesource.com/v8/v8/+/branch-heads/6.8/samples/hello-world.cc) that takes a JavaScript statement as a string argument, executes it as JavaScript code, and prints the result to standard out.
-
-First, some key concepts you will need:
-- An isolate is a VM instance with its own heap.
-- A local handle is a pointer to an object. All V8 objects are accessed using handles. They are necessary because of the way the V8 garbage collector works.
-- A handle scope can be thought of as a container for any number of handles. When you've finished with your handles, instead of deleting each one individually you can simply delete their scope.
-- A context is an execution environment that allows separate, unrelated, JavaScript code to run in a single instance of V8. You must explicitly specify the context in which you want any JavaScript code to be run.
-
-These concepts are discussed in greater detail in the [[Embedder's Guide|Embedder's Guide]].
-
-# Run the Example
-
-Follow the steps below to run the example yourself:
-
-1. Download the V8 source code by following the [[git|Using-Git]] instructions.
-1. The instructions for this hello world example have last been tested with V8 7.1.11. You can check out this branch with `git checkout refs/tags/7.1.11 -b sample -t`
-1. Create a build configuration using the helper script:
- ```bash
- tools/dev/v8gen.py x64.release.sample
- ```
- You can inspect and manually edit the build configuration by running
- ```bash
- gn args out.gn/x64.release.sample
- ```
-1. Build the static library on a Linux 64 system:
- ```bash
- ninja -C out.gn/x64.release.sample v8_monolith
- ```
-1. Compile `hello-world.cc`, linking to the static library created in the build process. For example, on 64bit Linux using the GNU compiler:
- ```bash
- g++ -I. -Iinclude samples/hello-world.cc -o hello_world -lv8_monolith -Lout.gn/x64.release.sample/obj/ -pthread -std=c++0x
- ```
-1. For more complex code, V8 will fail without an ICU data file. Copy this file to where your binary is stored:
- ```bash
- cp out.gn/x64.release.sample/icudtl.dat .
- ```
-1. Run the `hello_world` executable file at the command line.
-e.g. On Linux, in the V8 directory, run:
- ```bash
- ./hello_world
- ```
-1. You will see `Hello, World!`.
-
-Of course this is a very simple example and it's likely you'll want to do more than just execute scripts as strings! For more information see the [[Embedder's Guide|Embedder's Guide]]. If you are looking for an example which is in sync with master simply check out the file [`hello-world.cc`](https://chromium.googlesource.com/v8/v8/+/master/samples/hello-world.cc).
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/embed>.
diff --git a/Handling-of-Ports.md b/Handling-of-Ports.md
index 73c0be4..946b1f5 100644
--- a/Handling-of-Ports.md
+++ b/Handling-of-Ports.md
@@ -1,23 +1 @@
-# General
-This article describes how ports should be handled.
-
-# MIPS
-## Straight-forward MIPS ports
- 1. Do them yourself.
-
-## More complicated MIPS ports
- 1. CC the MIPS team in the CL. Use the mailing list v8-mips-ports.at.googlegroups.com for that purpose.
- 1. The MIPS team will land a CL afterwards to fix the port
-
-# PPC (not officially supported)
- 1. Contact/CC the PPC team in the CL if needed. Use the mailing list v8-ppc-ports.at.googlegroups.com for that purpose.
-
-# s390 (not officially supported)
- 1. Contact/CC the s390 team in the CL if needed. Use the mailing list v8-s390-ports.at.googlegroups.com for that purpose.
-
-# ARM
-## Straight-forward ARM ports
- 1. Do them yourself.
-
-## When you are lost
- 1. CC the ARM team in the CL. Use the mailing list v8-arm-ports.at.googlegroups.com for that purpose.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/ports>.
diff --git a/How-to-change-V8-public-API.md b/How-to-change-V8-public-API.md
index e735c9c..3a244cb 100644
--- a/How-to-change-V8-public-API.md
+++ b/How-to-change-V8-public-API.md
@@ -1,19 +1 @@
-V8 is used by many different embedders: Chrome, NodeJS, gjstest, etc. When changing V8 public API we need to ensure that the embedders can smoothly update to the new V8 version. In particular, we cannot assume that an embedder updates to the new V8 version and adjusts their code to the new API in one atomic change.
-
-The embedder should be able to adjust their code to the new API while still using the previous version of V8. All instructions below follow from this rule.
-
-* Adding new types, constants, and functions is safe with one caveat: do not add a new pure virtual function to an existing class. New virtual functions should have default implementation.
-* Adding a new parameter to a function is safe if the parameter has the default value.
-* Removing or renaming types, constants, functions is unsafe. Use [`V8_DEPRECATED`](https://cs.chromium.org/chromium/src/v8/include/v8config.h?rcl=6a01631187415688fdebf0c6aa5993c7f1b47b6f&l=316) and [`V8_DEPRECATE_SOON`](https://cs.chromium.org/chromium/src/v8/include/v8config.h?rcl=6a01631187415688fdebf0c6aa5993c7f1b47b6f&l=332) macros. For example, let's say we want to rename function `foo` to function `bar`. Then we need to do the following:
- * Add the new function `bar` near the existing function `foo`.
- * Wait until the CL rolls in Chrome. Adjust Chrome to use `bar`.
- * Annotate `foo` with `V8_DEPRECATED("Use bar instead", void foo());`
- * In the same CL adjust the tests that use `foo` to use `bar`.
- * Write in CL motivation for the change and high-level update instructions.
- * Wait until the next V8 branch.
- * Remove function `foo`.
-
- `V8_DEPRECATE_SOON` is a softer version of `V8_DEPRECATED`. Chrome will not break with it, so step b is not need. `V8_DEPRECATE_SOON` is not sufficient for removing the function. You still need to annotate with `V8_DEPRECATED` and wait for the next branch before removing the function.
- `V8_DEPRECATED` can be tested using `v8_deprecation_warnings` gn flag.
- `V8_DEPRECATE_SOON` can be tested using `v8_imminent_deprecation_warnings`.
-* Changing function signature is unsafe. Use `V8_DEPRECATED` and `V8_DEPRECATE_SOON` macros as described above.
+# This content has moved to <https://v8.dev/docs/api>.
diff --git a/Ignition.md b/Ignition.md
index f4867a5..efe302e 100644
--- a/Ignition.md
+++ b/Ignition.md
@@ -1,13 +1 @@
-V8 features an interpreter called Ignition. Ignition is a fast low-level register-based interpreter written using the backend of [[TurboFan]]. The V8 blog post presents a [high-level overview](https://v8project.blogspot.co.uk/2016/08/firing-up-ignition-interpreter.html) of the Ignition interpreter. More details can be found in the following resources:
-
-## Talks
-* [V8: Hooking up the Ignition to the Turbofan](https://docs.google.com/presentation/d/1chhN90uB8yPaIhx_h2M3lPyxPgdPmkADqSNAoXYQiVE/edit)
-* [Ignition: Jump-starting an Interpreter for V8](https://docs.google.com/presentation/d/1HgDDXBYqCJNasBKBDf9szap1j4q4wnSHhOYpaNy5mHU/edit#slide=id.g1357e6d1a4_0_58)
-* [Ignition: An Interpreter for V8](https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6HaCIu9wpZsrzqpIVIwQSuiXQ/edit) ([video](https://youtu.be/r5OWCtuKiAk))
-
-## Articles
-* [Understanding V8’s Bytecode](https://medium.com/dailyjs/understanding-v8s-bytecode-317d46c94775)
-
-## Design Docs
-* [Ignition design document](https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIPMh0uouUZLdyrtmMoL44/edit?ts=56f27d9d#heading=h.6jz9dj3bnr8t)
-* [Register Equivalence Optimization](https://docs.google.com/document/d/1wW_VkkIwhAAgAxLYM0wvoTEkq8XykibDIikGpWH7l1I/edit?ts=570d7131#heading=h.6jz9dj3bnr8t)
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/ignition>.
diff --git a/Introduction.md b/Introduction.md
index 49efa57..71beb6b 100644
--- a/Introduction.md
+++ b/Introduction.md
@@ -1,13 +1 @@
-Welcome to the developer documentation for V8. V8 is Google's open source, high performance JavaScript engine. It is written in C++ and is used in Google Chrome, Google's open source browser.
-
-This documentation is aimed at C++ developers who want to use V8 in their applications, as well as anyone interested in V8's design and performance. This document introduces you to V8, while the remaining documentation shows you how to use V8 in your code and describes some of its design details, as well as providing a set of JavaScript benchmarks for measuring V8's performance.
-
-# About V8
-
-V8 implements ECMAScript as specified in ECMA-262, 5th edition, and runs on Windows (XP or newer), Mac OS X (10.5 or newer), and Linux systems that use IA-32, x64, or ARM processors.
-
-V8 compiles and executes JavaScript source code, handles memory allocation for objects, and garbage collects objects it no longer needs. V8's stop-the-world, generational, accurate garbage collector is one of the keys to V8's performance. You can learn about this and other performance aspects in V8 Design Elements.
-
-JavaScript is most commonly used for client-side scripting in a browser, being used to manipulate Document Object Model (DOM) objects for example. The DOM is not, however, typically provided by the JavaScript engine but instead by a browser. The same is true of V8—Google Chrome provides the DOM. V8 does however provide all the data types, operators, objects and functions specified in the ECMA standard.
-
-V8 enables any C++ application to expose its own objects and functions to JavaScript code. It's up to you to decide on the objects and functions you would like to expose to JavaScript. There are many examples of applications that do this, for example: Adobe Flash and the Dashboard Widgets in Apple's Mac OS X and Yahoo! Widgets.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs>.
diff --git a/Memory-Leaks.md b/Memory-Leaks.md
index 4eed42d..c983c70 100644
--- a/Memory-Leaks.md
+++ b/Memory-Leaks.md
@@ -1,50 +1 @@
-_**(from Ulan's email)**_
-
-If you're investigating a memory leak and wonder why an object is not garbage collected, you can now use `%DebugTrackRetainingPath(object)` to print the actual retaining path of the object on each GC.
-
-This requires `--allow-natives-syntax --track-retaining-path` run-time flags and works both in release and debug modes. More info in the CL description.
-
-Consider the following `test.js`:
-
-```js
-function foo() {
- let x = { bar: "bar"};
- %DebugTrackRetainingPath(x);
- return () => { return x; }
-}
-let closure = foo();
-gc();
-```
-
-Example (use debug mode or `v8_enable_object_print = true` for much more verbose output):
-
-```
-$ out/x64.release/d8 --allow-natives-syntax --track-retaining-path --expose-gc test.js
-#################################################
-Retaining path for 0x245c59f0c1a1:
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Distance from root 6: 0x245c59f0c1a1 <Object map = 0x2d919f0d729>
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Distance from root 5: 0x245c59f0c169 <FixedArray[5]>
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Distance from root 4: 0x245c59f0c219 <JSFunction (sfi = 0x1fbb02e2d7f1)>
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Distance from root 3: 0x1fbb02e2d679 <FixedArray[5]>
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Distance from root 2: 0x245c59f0c139 <FixedArray[4]>
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Distance from root 1: 0x1fbb02e03d91 <FixedArray[279]>
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Root: (Isolate)
--------------------------------------------------
-```
-
-# Debugger Support
-While in a debugger session (e.g. gdb/lldb), and assuming you passed the above flags to the process (i.e. `--allow-natives-syntax --track-retaining-path`), you may be able to `print isolate->heap()->PrintRetainingPath(HeapObject*)` on an object of interest.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/memory-leaks>.
diff --git a/Merging-&-Patching.md b/Merging-&-Patching.md
index beac20c..0e045e3 100644
--- a/Merging-&-Patching.md
+++ b/Merging-&-Patching.md
@@ -1,98 +1 @@
-# Introduction
-
-If you have a patch to the master branch (e.g. an important bug fix) that needs to be merged into one of the production V8 branches, read on.
-
-For the examples, a branched 2.4 version of V8 will be used. Substitute "2.4" with your version number. See [[Release Process|Release Process]] for more information about version numbers.
-
-**An associated issue on Chromium's or V8's issue tracker is mandatory if a patch is merged. This helps with keeping track of merges.
-You can use [a template](https://code.google.com/p/v8/issues/entry?template=Merge%20request) to create an issue.**
-
-# What qualifies a merge candidate?
-
-* The patch fixes a *severe* bug (order of importance)
- 1. Security bug
- 1. Stability bug
- 1. Correctness bug
- 1. Performance bug
-* The patch does not alter APIs
-* The patch does not change behavior present before branch cut (except if the behavior change fixes a bug)
-
-More information can be found on the [relevant Chromium page](https://www.chromium.org/developers/the-zen-of-merge-requests). When in doubt, send an email to v8-dev@googlegroups.com.
-
-# Merge process outlined
-
-The merge process in the Chromium and V8 tracker is driven by labels in the form of
-```
-Merge-[Status]-[Branch]
-```
-The currently important labels for V8 are:
-
- 1. Merge-Request-{Branch} initiates the process => This fix should be merged into #.#
- 1. Merge-Review-{Branch} The merge is not approved yet for #.# e.g. because Canary coverage is missing
- 1. Merge-Approved-{Branch} => Simply means that the Chrome TPMs have signed off on the merge
- 1. Merge-Merged-{Branch} => When the merge is done, the Merge-Approved label is swapped with this one. {Branch} is the name/number of the V8 branch e.g. 4.3 for M-43.
-
-# Instructions for git using the automated script
-
-## How to check if a commit was already merged/reverted/has Canary coverage
-
-Use mergeinfo.py to get all the commits which are connected to the HASH according to Git.
-
-```
-tools/release/mergeinfo.py HASH
-```
-
-If it tells you ```Is on Canary: No Canary coverage``` you should not merge yet because the fix was not yet deployed on a Canary build. A good rule of the thumb is to wait at least 3 days after the fix has landed until the merge is conducted.
-
-## Step 1: Run the script
-
-Let's assume you're merging revision af3cf11 to branch 2.4 (please specify full git hashes - abbreviations are used here for simplicity).
-
-```
-tools/release/merge_to_branch.py --branch 2.4 af3cf11
-```
-
-Run the script with '-h' to display its help message, which includes more options (e.g. you can specify a file containing your patch, or you can reverse a patch, specify a custom commit message, or resume a merging process you've canceled before). Note that the script will use a temporary checkout of v8 - it won't touch your work space.
-You can also merge more than one revision at once, just list them all.
-
-```
-tools/release/merge_to_branch.py --branch 2.4 af3cf11 cf33f1b sf3cf09
-```
-
-In case you are a V8 committer, feel free to use TBR to land the merge if it 1.) has approval and 2.) the merge was clean and no conflicts to resolve.
-
-## Step 2: Observe the [branch waterfall](https://build.chromium.org/p/client.v8.branches/console)
-
-If one of the builders is not green after handling your patch, revert the merge immediately. A bot (AutoTagBot) will take care of the correct versioning after a 10 minute wait.
-
-# Patching a version used on Canary/Dev
-
-In case you need to patch a Canary/Dev version, which should not happen often
-follow these instructions:
-
-## Step 1: Merge to roll branch
-Example version used is 2.4.4.
-
- tools/release/roll_merge.py --branch 5.7.433 af3cf11
-
-## Step 2: Make Chromium aware of the fix
-Example Chromium branch used is 2978
-
- $ git checkout chromium/2978
- $ git merge 5.7.433.1
- $ git push
-
-## Step 3: The end
-
-Chrome/Chromium should should pick of the change when they build automatically.
-
-# FAQ
-
-## I get an error during merge that is related to tagging. What should I do?
-When two people are merging at the same time a race-condition can happen in the merge scripts. If this is the case, contact machenbach@chromium.org and hablich@chromium.org.
-## Is there a TL;DR?
- 1. [Create issue on issue tracker](https://code.google.com/p/v8/issues/entry?template=Merge%20request)
- 1. Check status of the fix with ```tools/release/mergeinfo.py```
- 1. Add Merge-Request-{Branch} to the issue
- 1. Wait until somebody adds Merge-Approved-{Branch}
- 1. [Merge](https://github.com/v8/v8/wiki/Merging-&-Patching#step-1-run-the-script)
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/merge-patch>.
diff --git a/Profiling-Chromium-with-v8.md b/Profiling-Chromium-with-v8.md
index 46cdac4..6559b4a 100644
--- a/Profiling-Chromium-with-v8.md
+++ b/Profiling-Chromium-with-v8.md
@@ -1,34 +1 @@
-# Introduction
-
-V8's CPU & Heap profilers are trivial to use from V8's shells (see V8Profiler), but it may appear confusing how to use them with Chromium. This page should help you with it.
-
-# Instructions
-
-## Why using V8's profilers with Chromium is different from using them with V8 shells?
-
-Chromium is a complex application, unlike V8 shells. Below is the list of Chromium features that affect profiler usage:
-
- * each renderer is a separate process (OK, not actually each, but let's omit this detail), so they can't share the same log file;
- * sandbox built around renderer process prevents it from writing to a disk;
- * Developer Tools configure profilers for their own purposes;
- * V8's logging code contains some optimizations to simplify logging state checks.
-
-## So, how to run Chromium to get a CPU profile?
-
-Here is how to run Chromium in order to get a CPU profile from the start of the process:
-```
-./Chromium --no-sandbox --js-flags="--logfile=%t.log --prof"
-```
-
-Please note that you wouldn't see profiles in Developer Tools, because all the data is being logged to a file, not to Developer Tools.
-
-### Flags description
-
- * **--no-sandbox** - turns off the renderer sandbox, obviously must have;
- * **--js-flags** - this is the containers for flags passed to V8:
- * **--logfile=%t.log** - specifies a name pattern for log files; **%t** gets expanded into current time in milliseconds, so each process gets its own log file; you can use prefixes and suffixes if you want, like this: **prefix-%t-suffix.log**;
- * **--prof** - tells V8 to write statistical profiling information into the log file.
-
-## Notes
-
-Under Windows, be sure to turn on .MAP file creation for **chrome.dll**, but not for **chrome.exe**.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/profile-chromium>.
diff --git a/Release-process.md b/Release-process.md
index 7d38e76..43fb813 100644
--- a/Release-process.md
+++ b/Release-process.md
@@ -1,60 +1 @@
-# Introduction
-
-The V8 release process is tightly connected to [Chrome's](https://www.chromium.org/getting-involved/dev-channel). The V8 team is using all four Chrome release channels to push new versions to the users.
-
-If you want to look up what V8 version is in a Chrome release you can check [OmahaProxy](https://omahaproxy.appspot.com/). For each Chrome release a separate branch is created in the V8 repository to make the trace-back easier e.g. for [Chrome 45.0.2413.0](https://chromium.googlesource.com/v8/v8.git/+/chromium/2413).
-
-# Canary releases
-Every day a new Canary build is pushed to the users via [Chrome's Canary channel](https://www.google.com/chrome/browser/canary.html?platform=win64). Normally the deliverable is the latest, stable enough version from [master](https://chromium.googlesource.com/v8/v8.git/+/roll).
-
-Branches for a Canary normally look like this
-
-```
-remotes/origin/4.5.35
-```
-
-# Dev releases
-
-Every week a new Dev build is pushed to the users via [Chrome’s Dev channel](https://www.google.com/chrome/browser/desktop/index.html?extra=devchannel&platform=win64). Normally the deliverable includes the latest stable enough V8 version on the Canary channel.
-
-Branches for a Dev normally look like this
-
-```
-remotes/origin/4.5.35
-```
-
-# Beta releases
-Roughly every 6 weeks a new major branch is created e.g. [for Chrome 44](https://chromium.googlesource.com/v8/v8.git/+log/branch-heads/4.4). This is happening in sync with the creation of [Chrome's Beta channel](https://www.google.com/chrome/browser/beta.html?platform=win64). The Chrome Beta is pinned to the head of V8's branch. After approx. 6 weeks the branch is promoted to Stable.
-
-Changes are only cherry-picked onto the branch in order to stabilize the version.
-
-Branches for a Beta normally look like this
-
-```
-remotes/branch-heads/4.5
-```
-
-They are based on a Canary branch.
-
-# Stable releases
-Roughly every 6 weeks a new major Stable release is done. No special branch is created as the latest Beta branch is simply promoted to Stable. This version is pushed to the users via [Chrome's Stable channel](https://www.google.com/chrome/browser/desktop/index.html?platform=win64).
-
-Branches for a Stable normally look like this
-
-```
-remotes/branch-heads/4.5
-```
-
-They are promoted (reused) Beta branches.
-
-# Which version should I embed in my application?
-
-The tip of the same branch that Chrome's Stable channel uses.
-
-We often backmerge important bug fixes to a stable branch, so if you care about stability and security and correctness, you should include those updates too -- that's why we recommend "the tip of the branch", as opposed to an exact version.
-
-As soon as a new branch is promoted to Stable, we stop maintaining the previous stable branch. This happens every six weeks, so you should be prepared to update at least this often.
-
-Example: The current stable Chrome release is [44.0.2403.125](https://omahaproxy.appspot.com), with V8 4.4.63.25. So you should embed [branch-heads/4.4](https://chromium.googlesource.com/v8/v8.git/+/branch-heads/4.4). And you should update to branch-heads/4.5 when Chrome 45 is released on the Stable channel.
-
-**Related:** [Which V8 version should I use?](https://github.com/v8/v8/wiki/Version-numbers#which-v8-version-should-i-use)
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/release-process>.
diff --git a/Reporting-security-bugs.md b/Reporting-security-bugs.md
index 4d71d68..c728b37 100644
--- a/Reporting-security-bugs.md
+++ b/Reporting-security-bugs.md
@@ -1,4 +1 @@
-V8 fully uses [Chromium's Security process](https://www.chromium.org/Home/chromium-security). In order to report a V8 security bug please follow these steps:
-
-1. Check [Chromium's guidelines for security bugs](https://www.chromium.org/Home/chromium-security/reporting-security-bugs)
-1. Create a [new bug](https://bugs.chromium.org/p/chromium/issues/entry?template=Security%20Bug) and add the component "Blink>JavaScript"
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/security-bugs>.
diff --git a/Stack-Trace-API.md b/Stack-Trace-API.md
index f83bf68..167391b 100644
--- a/Stack-Trace-API.md
+++ b/Stack-Trace-API.md
@@ -1,161 +1 @@
-All internal errors thrown in V8 capture a stack trace when they are created that can be accessed from JavaScript through the error.stack property. V8 also has various hooks for controlling how stack traces are collected and formatted, and for allowing custom errors to also collect stack traces. This document outlines V8's JavaScript stack trace API.
-
-# Basic stack traces
-
-By default, almost all errors thrown by V8 have a `stack` property that holds the topmost 10 stack frames, formatted as a string. Here's an example of a fully formatted stack trace:
-
-```
-ReferenceError: FAIL is not defined
- at Constraint.execute (deltablue.js:525:2)
- at Constraint.recalculate (deltablue.js:424:21)
- at Planner.addPropagate (deltablue.js:701:6)
- at Constraint.satisfy (deltablue.js:184:15)
- at Planner.incrementalAdd (deltablue.js:591:21)
- at Constraint.addConstraint (deltablue.js:162:10)
- at Constraint.BinaryConstraint (deltablue.js:346:7)
- at Constraint.EqualityConstraint (deltablue.js:515:38)
- at chainTest (deltablue.js:807:6)
- at deltaBlue (deltablue.js:879:2)
-```
-
-The stack trace is collected when the error is created and is the same regardless of where or how many times the error is thrown. We collect 10 frames because it is usually enough to be useful but not so many that it has a noticeable performance impact. You can control how many stack frames are collected by setting the variable
-
-```
-Error.stackTraceLimit
-```
-
-Setting it to 0 will disable stack trace collection. Any finite integer value will be used as the maximum number of frames to collect. Setting it to `Infinity` means that all frames will be collected. This variable only affects the current context, it has to be set explicitly for each context that needs a different value. (Note that what is known as a "context" in V8 terminology corresponds to a page or iframe in Google Chrome). To set a different default value that affects all contexts use the
-
-```
---stack-trace-limit <value>
-```
-
-command-line flag to V8. To pass this flag to V8 when running Google Chrome use
-
-```
---js-flags="--stack-trace-limit <value>"
-```
-
-### Stack trace collection for custom exceptions
-The stack trace mechanism used for built-in errors is implemented using a general stack trace collection API that is also available to user scripts. The function
-
-```
-Error.captureStackTrace(error, constructorOpt)
-```
-
-adds a stack property to the given `error` object that will yield the stack trace at the time captureStackTrace was called. Stack traces collected through `Error.captureStackTrace` are immediately collected, formatted, and attached to the given `error` object.
-
-The optional `constructorOpt` parameter allows you to pass in a function value. When collecting the stack trace all frames above the topmost call to this function, including that call, will be left out of the stack trace. This can be useful to hide implementation details that won't be useful to the user. The usual way of defining a custom error that captures a stack trace would be:
-
-```
-function MyError() {
- Error.captureStackTrace(this, MyError);
- // any other initialization
-}
-```
-
-Passing in MyError as a second argument means that the constructor call to MyError won't show up in the stack trace.
-
-# Customizing stack traces
-Unlike Java where the stack trace of an exception is a structured value that allows inspection of the stack state, the stack property in V8 just holds a flat string containing the formatted stack trace. This is for no other reason than compatibility with other browsers. However, this is not hardcoded but only the default behavior and can be overridden by user scripts.
-
-For efficiency stack traces are not formatted when they are captured but on demand, the first time the stack property is accessed. A stack trace is formatted by calling
-
-```
-Error.prepareStackTrace(error, structuredStackTrace)
-```
-
-and using whatever this call returns as the value of the `stack` property. If you assign a different function value to `Error.prepareStackTrace` that function will be used to format stack traces. It will be passed the error object that it is preparing a stack trace for and a structured representation of the stack. User stack trace formatters are free to format the stack trace however they want and even return non-string values. It is safe to retain references to the structured stack trace object after a call to prepareStackTrace completes so that it is also a valid return value. Note that the custom prepareStackTrace function is only called once the stack property of `Error` object is accessed.
-
-The structured stack trace is an Array of CallSite objects, each of which represents a stack frame. A CallSite object defines the following methods
-
- * **getThis**: returns the value of this
- * **getTypeName**: returns the type of this as a string. This is the name of the function stored in the constructor field of this, if available, otherwise the object's `[[Class]]` internal property.
- * **getFunction**: returns the current function
- * **getFunctionName**: returns the name of the current function, typically its name property. If a name property is not available an attempt will be made to try to infer a name from the function's context.
- * **getMethodName**: returns the name of the property of this or one of its prototypes that holds the current function
- * **getFileName**: if this function was defined in a script returns the name of the script
- * **getLineNumber**: if this function was defined in a script returns the current line number
- * **getColumnNumber**: if this function was defined in a script returns the current column number
- * **getEvalOrigin**: if this function was created using a call to eval returns a string representing the location where eval was called
- * **isToplevel**: is this a toplevel invocation, that is, is this the global object?
- * **isEval**: does this call take place in code defined by a call to eval?
- * **isNative**: is this call in native V8 code?
- * **isConstructor**: is this a constructor call?
-
-The default stack trace is created using the CallSite API so any information that is available there is also available through this API.
-
-To maintain restrictions imposed on strict mode functions, frames that have a strict mode function and all frames below (its caller etc.) are not allow to access their receiver and function objects. For those frames, `getFunction()` and `getThis()` will return `undefined`.
-
-# Compatibility
-The API described here is specific to V8 and is not supported by any other JavaScript implementations. Most implementations do provide an `error.stack` property but the format of the stack trace is likely to be different from the format described here. The recommended use of this API is
-
- * Only rely on the layout of the formatted stack trace if you know your code is running in v8.
- * It is safe to set `Error.stackTraceLimit` and `Error.prepareStackTrace` regardless of which implementation is running your code but be aware that it will only have an effect if your code is running in V8.
-
-# Appendix: Stack trace format
-The default stack trace format used by V8 can for each stack frame give the following information:
-
- * Whether the call is a construct call.
- * The type of the this value (Type).
- * The name of the function called (functionName).
- * The name of the property of this or one of its prototypes that holds the function (methodName).
- * The current location within the source (location)
-
-Any of these may be unavailable and different formats for stack frames are used depending on how much of this information is available. If all the above information is available a formatted stack frame will look like this:
-
-```
-at Type.functionName [as methodName] (location)
-```
-
-or, in the case of a construct call
-
-```
-at new functionName (location)
-```
-
-If only one of functionName and methodName is available, or if they are both available but the same, the format will be:
-
-```
-at Type.name (location)
-```
-
-If neither is available `<anonymous>` will be used as the name.
-
-The Type value is the name of the function stored in the constructor field of this. In v8 all constructor calls set this property to the constructor function so unless this field has been actively changed after the object was created it it will hold the name of the function it was created by. If it is unavailable the `[[Class]]` property of the object will be used.
-
-One special case is the global object where the Type is not shown. In that case the stack frame will be formatted as
-
-```
-at functionName [as methodName] (location)
-```
-
-The location itself has several possible formats. Most common is the file name, line and column number within the script that defined the current function
-
-```
-fileName:lineNumber:columnNumber
-```
-
-If the current function was created using eval the format will be
-
-```
-eval at position
-```
-
-where position is the full position where the call to eval occurred. Note that this means that positions can be nested if there are nested calls to eval, for instance:
-
-```
-eval at Foo.a (eval at Bar.z (myscript.js:10:3))
-```
-
-If a stack frame is within V8's libraries the location will be
-
-```
-native
-```
-
-and if is unavailable it will be
-
-```
-unknown location
-```
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/stack-trace-api>.
diff --git a/Suggested-Readings.md b/Suggested-Readings.md
index a00568c..dbcca19 100644
--- a/Suggested-Readings.md
+++ b/Suggested-Readings.md
@@ -1,7 +1 @@
-This page contains a list of articles and documents from the V8 team with tips and tricks on how to write idiomatic, optimizable JavaScript, and what pitfalls to avoid.
-
-# Articles and blog posts
-
-* [function.caller considered harmful](https://medium.com/@bmeurer/function-caller-considered-harmful-45f06916c907)
-* [Surprising polymorphism in React applications](https://medium.com/@bmeurer/surprising-polymorphism-in-react-applications-63015b50abc)
-* [Setting up prototypes in V8](https://medium.com/@tverwaes/setting-up-prototypes-in-v8-ec9c9491dfe2)
+# This content has moved to <https://v8.dev/>.
diff --git a/Testing.md b/Testing.md
index 4ea5f2a..dd3f3c8 100644
--- a/Testing.md
+++ b/Testing.md
@@ -1,108 +1 @@
-V8 includes a test framework that allows you to test the engine. The framework lets you run both our own test suites that are included with the source code and others, currently only the Mozilla tests.
-
-## Running the V8 tests
-
-Before you run the tests, [build V8 with GN](https://github.com/v8/v8/wiki/Building-with-GN).
-
-You can append `.check` to any build target to have tests run for it, e.g.
-```
-make ia32.release.check
-make ia32.check
-make release.check
-make check # builds and tests everything (no dot before "check"!)
-```
-
-Before submitting patches, you should always run the `quickcheck` target, which builds a fast debug build and runs only the most relevant tests:
-
-```
-make quickcheck
-```
-
-If you built V8 using GN, you can run tests like this:
-```
-tools/run-tests.py --gn
-```
-
-or if you want have multiple GN configurations and don't want to run the tests on the last compiled configuration:
-```
-tools/run-tests.py --outdir=out.gn/ia32.release
-```
-
-You can also run tests manually:
-```
-tools/run-tests.py --arch-and-mode=ia32.release [--outdir=foo]
-```
-
-Or you can run individual tests:
-```
-tools/run-tests.py --arch=ia32 cctest/test-heap/SymbolTable/* mjsunit/delete-in-eval
-```
-
-Run the script with `--help` to find out about its other options, `--outdir` defaults to `out`. Also note that using the `cctest` binary to run multiple tests in one process is not supported.
-
-## Running the Mozilla and Test262 tests
-
-The V8 test framework comes with support for running the Mozilla as well as the Test262 test suite. To download the test suites and then run them for the first time, do the following:
-
-```
-tools/run-tests.py --download-data mozilla
-tools/run-tests.py --download-data test262
-```
-
-To run the tests subsequently, you may omit the flag that downloads the test suite:
-
-```
-tools/run-tests.py mozilla
-tools/run-tests.py test262
-```
-
-Note that V8 fails a number of Mozilla tests because they require Firefox-specific extensions.
-
-## Running the WebKit tests
-
-Sometimes all of the above tests pass but WebKit build bots fail. To make sure WebKit tests pass run:
-
-```
-tools/run-tests.py --progress=verbose --outdir=out --arch=ia32 --mode=release webkit --timeout=200
-```
-
-Replace `--arch` and other parameters with values that match your build options.
-
-## Running Microbenchmarks
-
-Under `test/js-perf-test` we have microbenchmarks to track feature performance. There is a special runner for these: `tools/run_perf.py`. Run them like:
-```
-tools/run_perf.py --arch x64 --binary-override-path out.gn/x64.release/d8 test/js-perf-test/JSTests.json
-```
-
-If you don't want to run all the JSTests, you can provide a filter argument:
-```
-tools/run_perf.py --arch x64 --binary-override-path out.gn/x64.release/d8 --filter JSTests/TypedArrays test/js-perf-test/JSTests.json
-```
-
-## Updating the bytecode expectations
-
-Sometimes the bytecode expectations may change resulting in cctest failures. To update the golden files, build `test/cctest/generate-bytecode-expectations` by running:
-```
-ninja -C out.gn/x64.release generate-bytecode-expectations
-```
-
-and then updating the default set of inputs by passing the `--rebaseline` flag to the generated binary:
-```
-out.gn/x64.release/generate-bytecode-expectations --rebaseline
-```
-
-The updated goldens will be available in ` test/cctest/interpreter/bytecode_expectations/`.
-
-## Adding a new bytecode expectations test
-
-1) Add a new test case to `cctest/interpreter/test-bytecode-generator.cc` and specify a golden file with the same test name.
-2) Build `generate-bytecode-expectations` by running:
-```
-ninja -C out.gn/x64.release generate-bytecode-expectations
-```
-3) Run
-```
-out.gn/x64.release/generate-bytecode-expectations --raw-js testcase.js --output=test/cctest/interpreter/bytecode-expectations/testname.golden
-```
-where `testcase.js` contains the JavaScript test case that was added to `test-bytecode-generator.cc` and `testname` is the name of the test defined in `test-bytecode-generator.cc`.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/test>.
diff --git a/Tracing-V8.md b/Tracing-V8.md
index b6d8a88..1a598ef 100644
--- a/Tracing-V8.md
+++ b/Tracing-V8.md
@@ -1,39 +1 @@
-# Introduction
-
-Currently, V8 provides support for tracing. It works automatically when V8 is embedded in Chrome through the Chrome tracing system. But you can also enable it in any standalone V8 or within an embedder that uses the Default Platform.
-More details about the trace-viewer can be found [here](https://github.com/catapult-project/catapult/blob/master/tracing/README.md).
-
-# Tracing in d8
-To start tracing, use the `--enable-tracing` option. V8 generates a `v8_trace.json` that you can open in Chrome. To open it in Chrome, go to "chrome://tracing" then click on **Load** and then load the v8-trace.json file.
-
-Each trace event is a associated with a set of categories, you can enable/disable the recording of trace events based on their categories. With the above flag only, we only enable the default categories (a set of categories that has a low overhead). To enable more categories and have a more fine control of the different parameters you will need to pass a config file.
-An example of a config file `traceconfig.json`:
-```
-{
- "record_mode": "record-continuously",
- "included_categories": ["v8", "disabled-by-default-v8.runtime_stats"]
-}
-```
-
-An example of calling `d8` with tracing and a traceconfig file:
-```
-d8 --enable-tracing --trace-config=traceconfig.json
-```
-
-The trace config format is compatible with the one of Chrome Tracing, however, we don't support regular expression in included categories list, and V8 doesn't need excluded categories list, thus the trace config file for V8 can be reused in Chrome tracing, but you can't reuse Chrome trace config file in V8 tracing if the trace config file contains regular expression, besides, V8 will ignore excluded categories list.
-
-# Enabling Runtime Call Statistics in tracing
-
-To get Runtime Call Statistics, please record the trace with the following 2 categories enabled: `v8` and `disabled-by-default-v8.runtime_stats`. Each top level V8 trace event will contain the runtime statistics for the period of that event. By selecting any of those events in trace-viewer, the runtime stats table will be displayed in the lower panel, selecting multiple will create a merged view.
-
-
-
-# Enabling GC Object Statistics in tracing
-
-To get the GC Object Statistics in tracing, you need to collect a trace with `disabled-by-default-v8.gc_stats` category enabled also you need to use the following js-flags:
-```
---track_gc_object_stats --noincremental-marking
-```
-Once you load the trace in trace-viewer, search for slices named: `V8.GC_Object_Stats`, in the lower panel you will find the statistics. Selecting multiple slices will create a merged view.
-
-
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/trace>.
diff --git a/Triaging-issues.md b/Triaging-issues.md
index e2e7b9d..8d22182 100644
--- a/Triaging-issues.md
+++ b/Triaging-issues.md
@@ -1,25 +1 @@
-# How to get an issue triaged
-* *V8 tracker*: Set the state to `Untriaged`
-* *Chromium tracker*: Set the state to `Untriaged` and add the component `Blink>JavaScript`
-
-# How to assign V8 issues in the Chromium tracker
-Please move issues to the V8 specialty sheriffs queue of one of the
-following categories:
-
- * Memory: `component:blink>javascript status=Untriaged label:Performance-Memory`
- * Will show up in [this](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3Ablink%3Ejavascript+status%3DUntriaged+label%3APerformance-Memory+&colspec=ID+Pri+M+Stars+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles) query
- * Stability: `status=available,untriaged component:Blink>JavaScript label:Stability -label:Clusterfuzz`
- * Will show up in [this](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=status%3Davailable%2Cuntriaged+component%3ABlink%3EJavaScript+label%3AStability+-label%3AClusterfuzz&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids) query
- * No CC needed, will be triaged by a sheriff automatically
- * Performance: mvstanton@c....org
- * Clusterfuzz: Set the bug to the following state:
- * `label:ClusterFuzz component:Blink>JavaScript status:Untriaged`
- * Will show up in [this](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=label%3AClusterFuzz+component%3ABlink%3EJavaScript+status%3AUntriaged&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids) query.
- * No CC needed, will be triaged by a sheriff automatically
- * Security: All security issues are triaged by Chromium Security sheriffs. Please use the security template to create a new bug: https://bugs.chromium.org/p/chromium/issues/entry?template=Security+Bug
-
-If you need the attention of a sheriff, please consult the rotation information.
-
-Use the component `Blink>JavaScript` on all issues.
-
-**Please note that this only applies to issues tracked in the Chromium issue tracker.**
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/triage-issues>.
diff --git a/TurboFan.md b/TurboFan.md
index f6218e7..21254e9 100644
--- a/TurboFan.md
+++ b/TurboFan.md
@@ -1,43 +1 @@
-TurboFan is one of V8's optimizing compilers leveraging a concept called "[Sea of Nodes](http://darksi.de/d.sea-of-nodes/)". One of V8's blog posts offers a [high level overview](http://v8project.blogspot.de/2015/07/digging-into-turbofan-jit.html) of TurboFan. More detail can be found in the following resources:
-
-# Articles and blog posts
-
-* [A tale of TurboFan](http://benediktmeurer.de/2017/03/01/v8-behind-the-scenes-february-edition)
-* [Ignition+TurboFan and ES2015](http://benediktmeurer.de/2016/11/25/v8-behind-the-scenes-november-edition)
-* [An Introduction to Speculative Optimization in V8](https://ponyfoo.com/articles/an-introduction-to-speculative-optimization-in-v8)
-
-# Talks
-
-* [CodeStubAssembler: Redux](https://docs.google.com/presentation/d/1u6bsgRBqyVY3RddMfF1ZaJ1hWmqHZiVMuPRw_iKpHlY)
-* [An overview of the TurboFan compiler](https://docs.google.com/presentation/d/1H1lLsbclvzyOF3IUR05ZUaZcqDxo7_-8f4yJoxdMooU/edit)
-* [TurboFan IR](https://docs.google.com/presentation/d/1Z9iIHojKDrXvZ27gRX51UxHD-bKf1QcPzSijntpMJBM)
-* [TurboFan's JIT Design](https://docs.google.com/presentation/d/1sOEF4MlF7LeO7uq-uThJSulJlTh--wgLeaVibsbb3tc)
-* [Fast arithmetic for dynamic languages](https://docs.google.com/a/google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y)
-* [Deoptimization in V8](https://docs.google.com/presentation/d/1Z6oCocRASCfTqGq1GCo1jbULDGS-w-nzxkbVF7Up0u0)
-* [TurboFan: A new code generation architecture for V8](https://docs.google.com/presentation/d/1_eLlVzcj94_G4r9j9d_Lj5HRKFnq6jgpuPJtnmIBs88) ([video](https://www.youtube.com/watch?v=M1FBosB5tjM))
-* [An internship on laziness](https://docs.google.com/presentation/d/1AVu1wiz6Deyz1MDlhzOWZDRn6g_iFkcqsGce1F23i-M)
-
-# TurboFan Design Documents
-
-These are design documents that are mostly concerned with TurboFan internals.
-
-* [Function context specialization](https://docs.google.com/document/d/1CJbBtqzKmQxM1Mo4xU0ENA7KXqb1YzI6HQU8qESZ9Ic)
-* [Rest Parameters and Arguments Exotic Objects optimization plan](https://docs.google.com/document/d/1DvDx3Xursn1ViV5k4rT4KB8HBfBb2GdUy3wzNfJWcKM)
-* [TurboFan Developer Tools Integration](https://docs.google.com/document/d/1zl0IA7dbPffvPPkaCmLVPttq4BYIfAe2Qy8sapkYgRE)
-* [TurboFan Inlining](https://docs.google.com/document/d/1l-oZOW3uU4kSAHccaMuUMl_RCwuQC526s0hcNVeAM1E)
-* [TurboFan Inlining Heuristics](https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8)
-* [TurboFan Redundant Bounds and Overflow Check Elimination](https://docs.google.com/document/d/1R7-BIUnIKFzqki0jR4SfEZb3XmLafa04DLDrqhxgZ9U)
-* [Lazy deoptimization without code patching](https://docs.google.com/document/d/1ELgd71B6iBaU6UmZ_lvwxf_OrYYnv0e4nuzZpK05-pg)
-* [Register Allocator](https://docs.google.com/document/d/1aeUugkWCF1biPB4tTZ2KT3mmRSDV785yWZhwzlJe5xY)
-* [Projection Nodes in TurboFan](https://docs.google.com/document/d/1C9P8T98P1T_r2ymuUFz2jFWLUL7gbb6FnAaRjabuOMY/edit?usp=sharing)
-
-# Related Design Documents
-
-These are design documents that also affect TurboFan in a significant way.
-
-* [Computed property names (re)design document](https://docs.google.com/document/d/1eH1R6_C3lRrLtXKw0jNqAsqJ3cBecrqqvfRzLpfq7VE)
-* [ES2015 and beyond performance plan](https://docs.google.com/document/d/1EA9EbfnydAmmU_lM8R_uEMQ-U_v4l9zulePSBkeYWmY)
-* [Iterator builtins design document](https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8)
-* [Making ES2015 classes fast](https://docs.google.com/document/d/1iCdbXuGVV8BK750wmP32eF4sCrnZ8y3Qlz0JiaLh9j8)
-* [RegExp builtins (re)design document](https://docs.google.com/document/d/1MuqFjsfaRPL2ZqzVoeMRqtcAmcJSwmHljTbRIctVVUk)
-* [Spread Call Performance](https://docs.google.com/document/d/1DWPizOSKqHhSJ7bdEI0HIVnner84xToEKUYqgXm3g30)
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/turbofan>.
diff --git a/Untrusted-code-mitigations.md b/Untrusted-code-mitigations.md
index c14ee0b..74b9af1 100644
--- a/Untrusted-code-mitigations.md
+++ b/Untrusted-code-mitigations.md
@@ -1,32 +1 @@
-# Background
-
-On January 3rd, researchers from Google’s Project Zero disclosed [a new class of attacks](https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html) which [exploit](https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html) speculative execution optimizations used by many CPUs. Because V8 uses an optimizing JIT compiler, TurboFan, to make JavaScript run quickly, in certain circumstances it is vulnerable to the side-channel attacks described in the disclosure.
-
-# Nothing changes if you execute only trustworthy code
-
-If your product only uses an embedded instance of V8 to execute JavaScript or WebAssembly code that is entirely under your control, then your usage of V8 is likely unaffected by the Speculative Side-Channel Attacks (SSCA) vulnerability. A Node.js instance running only code that you trust is one such unaffected example.
-
-In order to take advantage of the vulnerability, an attacker has to execute carefully crafted JavaScript or WebAssembly code in your embedded environment. If, as a developer, you have complete control over the code executed in your embedded V8 instance, then that is very unlikely to be possible. However, if your embedded V8 instance allows arbitrary or otherwise untrustworthy JavaScript or WebAssembly code to be downloaded and executed, or even generates and subsequently executes JavaScript or WebAssembly code that isn’t fully under your control (e.g. if it uses either as a compilation target), you may need to consider mitigations.
-
-# If you do execute untrusted code…
-
-## Update to the latest V8 to benefit from mitigations
-
-Mitigations for this class of attack are available in V8 itself starting with [V8 v6.4.388.18](https://chromium.googlesource.com/v8/v8/+/e6eddfe4d1ed9d96b453d14b84ac19769388d8b1), so updating your embedded copy of V8 to [v6.4.388.18](https://chromium.googlesource.com/v8/v8/+/e6eddfe4d1ed9d96b453d14b84ac19769388d8b1) or later is advised. Older versions of V8, including versions of V8 that still use FullCodeGen and/or CrankShaft, do not have mitigations for SSCA.
-
-Starting in [V8 v6.4.388.18](https://chromium.googlesource.com/v8/v8/+/e6eddfe4d1ed9d96b453d14b84ac19769388d8b1), a new flag has been introduced to V8 to help provide protection against SSCA vulnerabilities. This flag, called `--untrusted-code-mitigations`, is enabled by default at runtime through a build-time GN flag called `v8_enable_untrusted_code_mitigations`.
-
-These mitigations are enabled by the `--untrusted-code-mitigations` flag:
-
-* Masking of addresses before memory accesses in WebAssembly and asm.js to ensure that speculatively executed memory loads cannot access memory outside of the WebAssembly and asm.js heaps.
-* Masking of the indices in JIT code used to access JavaScript arrays and strings in speculatively executed paths to ensure speculative loads cannot be made with arrays and string to memory addresses that should not accessible to JavaScript code.
-
-Embedders should be aware that the mitigations may come with a performance trade-off. The actual impact depends significantly on your workload. For workloads such as Speedometer the impact is negligible but for more extreme computational workloads it can be as much as 15%. If you fully trust the JavaScript and WebAssembly code that your embedded V8 instance executes, you may choose to disable these JIT mitigations by specifying the flag `--no-untrusted-code-mitigations` at runtime. The `v8_enable_untrusted_code_mitigations` GN flag can be used to disable the mitigations at build-time.
-
-## Sandbox untrusted execution in a separate process
-
-If you execute untrusted JavaScript and WebAssembly code in a separate process from any sensitive data, the potential impact of SSCA is greatly reduced. Through process isolation, SSCA attacks are only able to observe data that is sandboxed inside the same process along with the executing code, and not data from other processes.
-
-## Consider tuning your offered high-precision timers
-
-A high-precision timer makes it easier to observe side channels in the SSCA vulnerability. If your product offers high-precision timers that can be accessed by untrusted JavaScript or WebAssembly code, consider making these timers more coarse or adding jitter to them.
+# This content has moved to <https://v8.dev/docs/untrusted-code-mitigations>.
diff --git a/Using-D8.md b/Using-D8.md
index 3330cb5..9944622 100644
--- a/Using-D8.md
+++ b/Using-D8.md
@@ -1,68 +1 @@
-[D8](https://codesearch.chromium.org/chromium/src/v8/src/d8.h?q=d8&sq=package:chromium&l=5) (Debug8) is V8's own minimalist debug shell.
-
-D8 is useful for running some JavaScript locally or debugging changes you have made to V8. A normal V8 build using [[GN|Building with GN]] for x64 will output a D8 binary in `out.gn/x64.optdebug/d8`. You can call D8 with the `--help` argument for more information about usage and flags.
-
-## Print to the Command Line
-
-Printing output is probably going to be very important if you plan to use D8 to run JavaScript files, rather than interactively. This is very simple with the `print()` function:
-
-```
---- test.js ---
-print("Hello, World!");
-```
-```
-out.gn/x64.optdebug/d8 test.js
-> Hello, World!
-```
-
-## Read Input
-
-Using `read()` you can store the contents of a file into a variable.
-```
-d8> var license = read("LICENSE");
-d8> license
-"This license applies to all parts of V8 that are not externally
-maintained libraries. The externally maintained libraries used by V8
-are:
-... (etc.) "
-```
-
-Use `readline()` to interactively enter text:
-```
-d8> var greeting = readline();
-Welcome
-d8> greeting
-"Welcome"
-```
-
-## Load External Scripts
-`load()` runs another JavaScript file in the current context, meaning that you can then access anything declared in that file.
-
-```
---- util.js ---
-function greet(name) {
- return "Hello, " + name;
-}
-```
-```
-d8> load('util.js');
-d8> greet('World!');
-"Hello, World!"
-```
-
-## Pass Flags Into JavaScript
-
-It's possible to make command line arguments available to your JavaScript code at runtime with D8. Just pass them after `--` on the command line and you will be able to access them at the top level of your script using the `arguments` object.
-
-```
-out.gn/x64.optdebug/d8 -- hi
-```
-You can now access an array of the arguments using the `arguments` object:
-```
-d8> arguments[0]
-"hi"
-d8>
-```
-
-## More Resources
-[Kevin Ennis' D8 Guide](https://gist.github.com/kevincennis/0cd2138c78a07412ef21) has really good information about exploring V8 using D8.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/d8>.
diff --git a/Using-Git.md b/Using-Git.md
index 86bce44..4928002 100644
--- a/Using-Git.md
+++ b/Using-Git.md
@@ -1,142 +1 @@
-# Git repository
-
-V8's git repository is located at https://chromium.googlesource.com/v8/v8.git
-
-V8's master branch has also an official git mirror on github: http://github.com/v8/v8-git-mirror.
-
-**Don't just `git-clone` either of these URLs** if you want to build V8 from your checkout, instead follow the instructions below to get everything set up correctly.
-
-## Prerequisites
-
- 1. **Git**. To install using `apt-get`:
-```
-apt-get install git
-```
- 1. **depot\_tools**. See [instructions](http://dev.chromium.org/developers/how-tos/install-depot-tools).
- 1. For **push access**, you need to setup a .netrc file with your git password:
- 1. Go to https://chromium.googlesource.com/new-password - login with your committer account (e.g. @chromium.org account, non-chromium.org ones work too). Note: creating a new password doesn't automatically revoke any previously created passwords. Please make sure you use the same email as the one set for `git config user.email`.
- 1. Have a look at the big, grey box containing shell commands. Paste those lines into your shell.
-
-## How to start
-
-Make sure depot\_tools are up-to-date by typing once:
-
-```
-gclient
-```
-
-
-Then get V8, including all branches and dependencies:
-
-```
-mkdir ~/v8
-cd ~/v8
-fetch v8
-cd v8
-```
-
-After that you're intentionally in a detached head state.
-
-Optionally you can specify how new branches should be tracked:
-
-```
-git config branch.autosetupmerge always
-git config branch.autosetuprebase always
-```
-
-Alternatively, you can create new local branches like this (recommended):
-
-```
-git new-branch mywork
-```
-
-## Staying up-to-date
-
-Update your current branch with git pull. Note that if you're not on a branch, git pull won't work, and you'll need to use git fetch instead.
-
-```
-git pull
-```
-
-Sometimes dependencies of v8 are updated. You can synchronize those by running
-
-```
-gclient sync
-```
-
-## Sending code for reviewing
-
-```
-git cl upload
-```
-
-## Committing
-
-You can use the CQ checkbox on codereview for committing (preferred). See also the [chromium instructions](http://www.chromium.org/developers/testing/commit-queue) for CQ flags and troubleshooting.
-
-If you need more trybots than the default, add the following to your commit message on rietveld (e.g. for adding a nosnap bot):
-
-```
-CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
-```
-
-To land manually, update your branch:
-
-```
-git pull --rebase origin
-```
-
-Then commit using
-
-```
-git cl land
-```
-
-# For project members
-
-
-## Try jobs
-
-### Creating a try job from codereview
-
- 1. Upload a CL to rietveld.
-```
-git cl upload
-```
- 1. Try the CL by sending a try job to the try bots like this:
-```
-git cl try
-```
- 1. Wait for the try bots to build and you will get an e-mail with the result. You can also check the try state at your patch on codereview.
- 1. If applying the patch fails you either need to rebase your patch or specify the v8 revision to sync to:
-```
-git cl try --revision=1234
-```
-
-### Creating a try job from a local branch
-
- 1. Commit some changes to a git branch in the local repo.
- 1. Try the change by sending a try job to the try bots like this:
-```
-git cl try
-```
- 1. Wait for the try bots to build and you will get an e-mail with the result. Note: There are issues with some of the slaves at the moment. Sending try jobs from codereview is recommended.
-
-### Useful arguments
-
-The revision argument tells the try bot what revision of the code base will be used for applying your local changes to. Without the revision, our LKGR revision is used as the base (http://v8-status.appspot.com/lkgr).
-```
-git cl try --revision=1234
-```
-To avoid running your try job on all bots, use the --bot flag with a comma-separated list of builder names. Example:
-```
-git cl try --bot=v8_mac_rel
-```
-
-### Viewing the try server
-
-http://build.chromium.org/p/tryserver.v8/waterfall
-
-### Access credentials
-
-If asked for access credentials, use your @chromium.org email address and your generated password from [googlecode.com](http://code.google.com/hosting/settings).
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/source-code#using-git>.
diff --git "a/Using-V8\342\200\231s-internal-profiler.md" "b/Using-V8\342\200\231s-internal-profiler.md"
index bed6014..7e41bb6 100644
--- "a/Using-V8\342\200\231s-internal-profiler.md"
+++ "b/Using-V8\342\200\231s-internal-profiler.md"
@@ -1,61 +1 @@
-Today's highly optimized virtual machines can run web apps at blazing speed. But one shouldn't rely only on them to achieve great performances: a carefully optimized algorithm or a less expensive function can often reach many-fold speed improvements on all browsers. [Chrome DevTools](https://developers.google.com/web/tools/chrome-devtools/)' [CPU Profiler](https://developers.google.com/web/tools/chrome-devtools/profile/?hl=en) helps you analyze your code bottlenecks. But sometimes, you need to go deeper and more granular: this is where V8's internal [profiler](V8 Profiler) comes in handy.
-
-Let’s use that profiler to examine the [Mandelbrot explorer demo](http://ie.microsoft.com/testdrive/performance/mandelbrotexplorer/) that Microsoft [released](http://blogs.msdn.com/b/ie/archive/2012/11/13/ie10-fast-fluid-perfect-for-touch-and-available-now-for-windows-7.aspx) together with IE10. After the demo release, V8 has fixed a bug that slowed down the computation unnecessarily (hence the poor performance of Chrome in the demo’s blog post) and further optimized the engine, implementing a faster exp() approximation than what the standard system libraries provide. Following these changes, **the demo ran 8x faster than previously measured** in Chrome.
-
-But what if you want the code to run faster on all browsers? You should first **understand what keeps your CPU busy**. Run Chrome (Windows and Linux [Canary](https://tools.google.com/dlpage/chromesxs)) with the following command line switches, which will cause it to output profiler tick information (in the `v8.log` file) for the URL you specify, which in our case was a local version of the Mandelbrot demo without web workers:
-
-```
-$ ./chrome --js-flags=”--prof” --no-sandbox http://localhost:8080/index.html
-```
-
-When preparing the test case, make sure it begins its work immediately upon load, and simply close Chrome when the computation is done (hit Alt+F4), so that you only have the ticks you care about in the log file. Also note that web workers aren’t yet profiled correctly with this technique.
-
-Then, process the `v8.log` file with the tick-processor script that ships with V8 (or the new practical web version):
-
-```
-$ v8/tools/linux-tick-processor v8.log
-```
-
-Here’s an interesting snippet of the processed output that should catch your attention:
-
-```
-Statistical profiling result from null, (14306 ticks, 0 unaccounted, 0 excluded).
- [Shared libraries]:
- ticks total nonlib name
- 6326 44.2% 0.0% /lib/x86_64-linux-gnu/libm-2.15.so
- 3258 22.8% 0.0% /.../chrome/src/out/Release/lib/libv8.so
- 1411 9.9% 0.0% /lib/x86_64-linux-gnu/libpthread-2.15.so
- 27 0.2% 0.0% /.../chrome/src/out/Release/lib/libwebkit.so
-```
-
-The top section shows that V8 is spending more time inside an OS-specific system library than in its own code. Let’s look at what’s responsible for it by examining the “bottom up” output section, where you can read indented lines as "was called by" (and lines starting with a * mean that the function has been optimized by Crankshaft):
-
-```
-[Bottom up (heavy) profile]:
- Note: percentage shows a share of a particular caller in the total
- amount of its parent calls.
- Callers occupying less than 2.0% are not shown.
-
- ticks parent name
- 6326 44.2% /lib/x86_64-linux-gnu/libm-2.15.so
- 6325 100.0% LazyCompile: *exp native math.js:91
- 6314 99.8% LazyCompile: *calculateMandelbrot http://localhost:8080/Demo.js:215
-```
-
-More than **44% of the total time is spent executing the exp() function inside a system library**! Adding some overhead for calling system libraries, that means about two thirds of the overall time are spent evaluating Math.exp().
-
-If you look at the JavaScript code, you’ll see that exp() is used solely to produce a smooth grayscale palette. There are countless ways to produce a smooth grayscale palette, but let’s suppose you really really like exponential gradients. Here is where algorithmic optimization comes into play.
-
-You’ll notice that exp() is called with an argument in the range -4 < x < 0, so we can safely replace it with its Taylor approximation for that range, which will deliver the same smooth gradient with only a multiplication and a couple of divisions:
-
-```
-exp(x) ≈ 1 / ( 1 - x + x*x / 2) for -4 < x < 0
-```
-
-Tweaking the algorithm this way boosts the performance by an extra 30% compared to latest Canary and 5x to the system library based Math.exp() on Chrome Canary.
-
-
-
-This example shows how V8’s internal profiler can help you go deeper into understanding your code bottlenecks, and that a smarter algorithm can push performance even further.
-
-To compare VM performances that represents today’s complex and demanding web applications, one might also want to consider a more comprehensive set of benchmarks such as the [Octane Javascript Benchmark Suite](http://chromium.github.io/octane/).
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/profile>.
diff --git a/V8-Linux-perf-Integration.md b/V8-Linux-perf-Integration.md
index d863251..f3f8fb5 100644
--- a/V8-Linux-perf-Integration.md
+++ b/V8-Linux-perf-Integration.md
@@ -1,64 +1 @@
-# Introduction
-
-V8 has built-in support for the Linux perf tool. By default, this support is disabled, but by using the --perf-prof and --perf-prof-debug-info command line options, V8 will write out performance data during execution into a file that can be used to analyze the performance of V8's JITted code with the Linux perf tool.
-
-# Setup
-
-In order to analyze V8 JIT code with the Linux perf tool you will need to:
-- Use a very recent Linux kernel that provides high-resolution timing information to the perf tool and to V8's perf integration in order to synchronize JIT code performance samples with the standard performance data collected by the Linux perf tool.
-- Use a recent very recent version of the Linux perf tool or apply the patch that supports JIT code to perf and build it yourself.
-
-Install a new Linux kernel, and then reboot your machine:
-```
-sudo apt-get install linux-generic-lts-wily
-```
-
-Install dependencies:
-```
-sudo apt-get install libdw-dev libunwind8-dev systemtap-sdt-dev libaudit-dev libslang2-dev binutils-dev liblzma-dev
-```
-
-Download kernel sources that includes the latest perf tool source:
-```
-cd <path_to_kernel_checkout>
-git clone --depth 1 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
-cd tip/tools/perf
-make
-```
-
-# Build
-
-To use V8's integration with Linux perf you need to build it with the appropriate GN build flag activated. You can set "enable_profiling = true" in an existing GN build configuration.
-```
-echo "enable_profiling = true" >> out.gn/x64.release/args.gn
-ninja -C out.gn/x64.release
-```
-
-Alternatively, you create a new clean build configuration with only the single build flag set to enable perf support:
-```
-cd <path_to_your_v8_checkout>
-tools/dev/v8gen.py x64.release
-echo "enable_profiling = true" >> out.gn/x64.release/args.gn
-ninja -C out.gn/x64.release
-```
-
-# Running d8 with perf flags
-
-Once you have the right kernel, perf tool and build of V8, you can add the --perf-prof to the V8 command line to record performance samples in JIT code. Here's an example that records samples from a test JavaScript file:
-```
-cd <path_to_your_v8_checkout>
-echo "(function f() { var s = 0; for (var i = 0; i < 1000000000; i++) { s += i; } return s; })();" > test.js
-<path_to_kernel_checkout>/tip/tools/perf/perf record -k mono out.gn/x64.release/d8 --perf-prof test.js
-```
-
-# Evaluating perf output
-
-After execution finishes, you must combine the static information gathered from the perf tool with the performance samples output by V8 for JIT code:
-```
-<path_to_kernel_checkout>/tip/tools/perf/perf inject -j -i perf.data -o perf.data.jitted
-```
-
-Finally you can use the Linux perf tool to explore the performance bottlenecks in your JITted code:
-```
-<path_to_kernel_checkout>/tip/tools/perf/perf report -i perf.data.jitted
-```
+# This content has moved to <https://v8.dev/docs/linux-perf>.
diff --git a/V8-Profiler.md b/V8-Profiler.md
index 2dc7fea..7e41bb6 100644
--- a/V8-Profiler.md
+++ b/V8-Profiler.md
@@ -1,145 +1 @@
-# Introduction
-
-V8 has built-in sample based profiling. Profiling is turned off by default, but can be enabled via the `--prof` command line option. The sampler records stacks of both JavaScript and C/C++ code.
-
-# Build
-Build the d8 shell following the instructions at [[Building with GN|Building with GN]].
-
-
-# Command Line
-To start profiling, use the `--prof` option. When profiling, V8 generates a `v8.log` file which contains profiling data.
-
-Windows:
-```
-build\Release\d8 --prof script.js
-```
-
-Other platforms (replace "ia32" with "x64" if you want to profile the x64 build):
-```
-out/ia32.release/d8 --prof script.js
-```
-
-# Process the Generated Output
-
-Log file processing is done using JS scripts running by the d8 shell. For this to work, a `d8` binary (or symlink, or `d8.exe` on Windows) must be in the root of your V8 checkout, or in the path specified by the environment variable `D8_PATH`. Note: this binary is just used to process the log, but not for the actual profiling, so it doesn't matter which version etc. it is.
-
-**Make sure `d8` used for analysis was not build with `is_component_build`!**
-
-Windows:
-```
-tools\windows-tick-processor.bat v8.log
-```
-
-Linux:
-```
-tools/linux-tick-processor v8.log
-```
-
-Mac OS X:
-```
-tools/mac-tick-processor v8.log
-```
-
-## Web UI for --prof
-
-Preprocess the log with `--preprocess` (to resolve C++ symbols, etc).
-
-
-```
-$V8_PATH/tools/linux-tick-processor --preprocess > v8.json
-```
-
-Open the browser at [tools/profview/index.html](https://github.com/v8/v8/blob/master/tools/profview/index.html) and select the `v8.json` file there.
-
-## Snapshot-based VM build and builtins reporting
-
-When a snapshot-based VM build is being used, code objects from a snapshot that don't correspond to functions are reported with generic names like _"A builtin from the snapshot"_, because their real names are not stored in the snapshot. To see the names the following steps must be taken:
-
- * `--log-snapshot-positions` flag must be passed to VM (along with `--prof`); this way, for deserialized objects the `(memory address, snapshot offset)` pairs are being emitted into profiler log;
-
- * `--snapshot-log=<log file from mksnapshot>` flag must be passed to the tick processor script; a log file from the `mksnapshot` program (a snapshot log) contains address-offset pairs for serialized objects, and their names; using the snapshot log, names can be mapped onto deserialized objects during profiler log processing; the snapshot log file is called `snapshot.log` and resides alongside with V8's compiled files.
-
-An example of usage:
-```
-out/ia32.release/d8 --prof --log-snapshot-positions script.js
-tools/linux-tick-processor --snapshot-log=out/ia32.release/obj.target/v8_snapshot/geni/snapshot.log v8.log
-```
-
-# Example Output
-
-```
-Statistical profiling result from benchmarks\v8.log, (4192 ticks, 0 unaccounted, 0 excluded).
-
- [Shared libraries]:
- ticks total nonlib name
- 9 0.2% 0.0% C:\WINDOWS\system32\ntdll.dll
- 2 0.0% 0.0% C:\WINDOWS\system32\kernel32.dll
-
- [JavaScript]:
- ticks total nonlib name
- 741 17.7% 17.7% LazyCompile: am3 crypto.js:108
- 113 2.7% 2.7% LazyCompile: Scheduler.schedule richards.js:188
- 103 2.5% 2.5% LazyCompile: rewrite_nboyer earley-boyer.js:3604
- 103 2.5% 2.5% LazyCompile: TaskControlBlock.run richards.js:324
- 96 2.3% 2.3% Builtin: JSConstructCall
- ...
-
- [C++]:
- ticks total nonlib name
- 94 2.2% 2.2% v8::internal::ScavengeVisitor::VisitPointers
- 33 0.8% 0.8% v8::internal::SweepSpace
- 32 0.8% 0.8% v8::internal::Heap::MigrateObject
- 30 0.7% 0.7% v8::internal::Heap::AllocateArgumentsObject
- ...
-
-
- [GC]:
- ticks total nonlib name
- 458 10.9%
-
- [Bottom up (heavy) profile]:
- Note: percentage shows a share of a particular caller in the total
- amount of its parent calls.
- Callers occupying less than 2.0% are not shown.
-
- ticks parent name
- 741 17.7% LazyCompile: am3 crypto.js:108
- 449 60.6% LazyCompile: montReduce crypto.js:583
- 393 87.5% LazyCompile: montSqrTo crypto.js:603
- 212 53.9% LazyCompile: bnpExp crypto.js:621
- 212 100.0% LazyCompile: bnModPowInt crypto.js:634
- 212 100.0% LazyCompile: RSADoPublic crypto.js:1521
- 181 46.1% LazyCompile: bnModPow crypto.js:1098
- 181 100.0% LazyCompile: RSADoPrivate crypto.js:1628
- ...
-```
-
-# Timeline plot
-The timeline plot visualizes where V8 is spending time. This can be used to find bottlenecks and spot things that are unexpected (for example, too much time spent in the garbage collector). Data for the plot are gathered by both sampling and instrumentation. Linux with gnuplot 4.6 is required.
-
-To create a timeline plot, run V8 as described above, with the option `--log-timer-events` additional to `--prof`:
-```
-out/ia32.release/d8 --prof --log-timer-events script.js
-```
-
-The output is then passed to a plot script, similar to the tick-processor:
-```
-tools/plot-timer-events v8.log
-```
-
-This creates `timer-events.png` in the working directory, which can be opened with most image viewers.
-
-# Options
-Since recording log output comes with a certain performance overhead, the script attempts to correct this using a distortion factor. If not specified, it tries to find out automatically. You can however also specify the distortion factor manually.
-```
-tools/plot-timer-events --distortion=4500 v8.log
-```
-
-You can also manually specify a certain range for which to create the plot or statistical profile, expressed in milliseconds:
-```
-tools/plot-timer-events --distortion=4500 --range=1000,2000 v8.log
-tools/linux-tick-processor --distortion=4500 --range=1000,2000 v8.log
-```
-
-# HTML 5 version
-Both statistical profile and timeline plot are available [in the browser](https://chromium.googlesource.com/v8/v8.git/+/master/tools/profviz/profviz.html). However, the statistical profile lacks C++ symbol resolution and the Javascript port of gnuplot performs an order of magnitude slower than the native one.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/profile>.
diff --git a/Version-numbers.md b/Version-numbers.md
index 4acfe6f..34cf0ab 100644
--- a/Version-numbers.md
+++ b/Version-numbers.md
@@ -1,60 +1 @@
-## Version numbering scheme
-
-V8 version numbers are of the form `x.y.z.w`, where:
-
-- `x.y` is the Chromium milestone divided by 10 (e.g. M60 → `6.0`)
-- `z` is automatically bumped whenever there’s a new [LKGR](https://www.chromium.org/glossary#TOC-Acronyms) (typically a few times per day)
-- `w` is bumped for manually backmerged patches after a branch point
-
-If `w` is `0`, it’s omitted from the version number. E.g. v5.9.211 (instead of “v5.9.211.0”) gets bumped up to v5.9.211.1 after backmerging a patch.
-
-## Which V8 version should I use?
-
-Embedders of V8 should generally use *the head of the branch corresponding to the minor version of V8 that ships in Chrome*.
-
-### Finding the minor version of V8 corresponding to the latest stable Chrome
-
-To find out what version this is,
-
-1. Go to <https://omahaproxy.appspot.com/>
-2. Find the latest stable Chrome version in the table
-3. Check the `v8_version` column (to the right) on the same row
-
-_Example: at the time of this writing, the site indicates that for `mac`/`stable`, the Chrome release version is 59.0.3071.86, which corresponds to V8 version 5.9.211.31._
-
-### Finding the head of the corresponding branch
-
-V8’s version-related branches do not appear in the online repository at <https://chromium.googlesource.com/v8/v8.git>; instead only tags appear. To find the head of that branch, go to the URL in this form:
-
-```
-https://chromium.googlesource.com/v8/v8.git/+/branch-heads/<minor-version>
-```
-
-_Example: for the V8 minor version 5.9 found above, we go to <https://chromium.googlesource.com/v8/v8.git/+/branch-heads/5.9>, finding a commit titled “Version 5.9.211.33”. Thus, the version of V8 that embedders should use at the time of this writing is **5.9.211.33**._
-
-**Caution:** You should *not* simply find the numerically-greatest tag corresponding to the above minor V8 version, as sometimes those are not supported, e.g. they are tagged before deciding where to cut minor releases. Such versions do not receive backports or similar.
-
-_Example: the V8 tags `5.9.212`, `5.9.213`, `5.9.214`, `5.9.214.1`, …, and `5.9.223` are abandoned, despite being numerically greater than the **branch head** of 5.9.211.33._
-
-### Checking out the head of the corresponding branch
-
-If you have the source already, you can check out the head somewhat directly. If you’ve retrieved the source using `depot_tools` then you should be able to do
-
-```sh
-$ git branch --remotes | grep branch-heads/
-```
-
-to list the relevant branches. You'll want to check out the one corresponding to the minor V8 version you found above, and use that. The tag that you end up on is the appropriate V8 version for you as the embedder.
-
-If you did not use `depot_tools`, edit `.git/config` and add the line below to the `[remote "origin"]` section:
-
-```
-fetch = +refs/branch-heads/*:refs/remotes/branch-heads/*
-```
-
-_Example: for the V8 minor version 5.9 found above, we can do_
-
-```sh
-$ git checkout branch-heads/5.9
-HEAD is now at 8c3db649d8... Version 5.9.211.33
-```
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/version-numbers>.
diff --git a/What-to-do-if-your-CL-broke-the-Node.js-integration-build.md b/What-to-do-if-your-CL-broke-the-Node.js-integration-build.md
index b7c2b37..1cdc112 100644
--- a/What-to-do-if-your-CL-broke-the-Node.js-integration-build.md
+++ b/What-to-do-if-your-CL-broke-the-Node.js-integration-build.md
@@ -1,89 +1 @@
-## Background
-[Node master](https://github.com/nodejs/node) uses V8 stable or beta. For additional integration, the V8 team builds Node with [V8 master](https://chromium.googlesource.com/v8/v8.git), i.e., with a V8 version from today. We provide integration bots for [Linux](https://build.chromium.org/p/client.v8.fyi/builders/V8%20Linux64%20-%20node.js%20integration), [Windows](https://build.chromium.org/p/client.v8.fyi/builders/V8%20Win64%20-%20node.js%20integration), and [Mac](https://build.chromium.org/p/client.v8.fyi/builders/V8%20Mac64%20-%20node.js%20integration). For each successful build, the integration bot provides an *Archive link* from which you can download a Node executable (click on the `Build #` and search for `Archive`).
-
-If the [`v8_node_linux64_rel` bot](https://ci.chromium.org/p/v8/builders/luci.v8.try/v8_node_linux64_rel) fails on the V8 Commit Queue, there is either a legitimate problem with your CL (fix it) or [Node](https://github.com/v8/node/) must be modified. If the Node tests failed, search for "Not OK" in the logfiles. **This document describes how to reproduce the problem locally and how to make changes to [V8’s Node fork](https://github.com/v8/node/) if your V8 CL causes the build to fail.**
-
-*Note: Patches in V8’s fork are usually cherry-picked by the person who updates V8 in [Node](https://github.com/nodejs/node) (usually several weeks or month later). If you merged a fix to V8’s Node fork, there’s nothing else you need to do.*
-
-# Reproduce locally
-Clone V8’s Node repository and check out the lkgr branch.
-```
-git clone https://github.com/v8/node.git
-git checkout -b vee-eight-lkgr origin/vee-eight-lkgr
-```
-
-Or, if you already have a Node checkout, add v8/node as remote.
-
-```
-cd $NODE
-git remote add v8-fork git@github.com:v8/node.git
-git checkout -b vee-eight-lkgr v8-fork/vee-eight-lkgr
-```
-
-Apply your patch, i.e., replace node/deps/v8 with a copy of v8 (lkgr branch) and build Node.
-```
-$V8/tools/node/update_node.py $V8 $NODE
-cd $NODE
-./configure --build-v8-with-gn && make -j48 test
-```
-You can run single tests.
-```
-./node test/parallel/test-that-you-want.js
-```
-For debug builds, set v8_optimized_debug in common.gypi to true and run
-```
-./configure --debug --build-v8-with-gn && make -j48 test
-```
-
-To run the debug binary, run `./node_g` rather than `./node`
-
-# Make changes to Node.js
-If you need to change something in [Node](https://github.com/v8/node/) so your CL doesn’t break the [build](https://build.chromium.org/p/client.v8.fyi/builders/V8%20-%20node.js%20integration) anymore, do the following. **You need a GitHub account for this**.
-
-### Get the Node sources
-Fork [V8’s Node repository on Github](https://github.com/v8/node/) (click the fork button). Clone your Node repository and check out the lkgr branch.
-```
-git clone git@github.com:your_user_name/node.git
-```
-If you already have a checkout of your fork of Node, you do not fork the repo. Instead, add v8/node as remote:
-```
-cd $NODE
-git remote add v8-fork git@github.com:v8/node.git
-git checkout -b vee-eight-lkgr v8-fork/vee-eight-lkgr
-```
-Make sure you have the correct branch and check that the current version builds and runs. Then create a new branch for your fix.
-```
-git checkout vee-eight-lkgr
-./configure --build-v8-with-gn && make -j48 test
-git checkout -b fix-something
-```
-### Apply your patch
-
-Replace node/deps/v8 with a copy of v8 (lkgr branch) and build Node.
-```
-$V8/tools/node/update_node.py $V8 $NODE
-cd $NODE
-./configure --build-v8-with-gn && make -j48 test
-```
-
-The ninja build is quite a bit faster, but does not offer a `test` target.
-```
-./configure --build-v8-with-gn && autoninja -C out/Release
-tools/test.py
-```
-
-### Make fixes to Node
-
-Make your changes to Node (not to deps/v8) and commit them.
-```
-git commit -m "subsystem: fix something"
-```
-*Note: if you make several commits, please squash them into one and format according to [Node’s guidelines](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#commit-guidelines). Github’s review works differently than V8 Chromium and your commit messages will end up in Node exactly how you wrote them locally (doesn’t matter what you type in the PR message). It’s OK to force push onto your fix-something branch.*
-
-Build and run the tests again. Double check that your formatting looks like the rest of the file.
-```
-./configure --build-v8-with-gn && make -j48 test
-make lint
-git push origin fix-something
-```
-Once you have pushed the fixes to your repository, open a Pull Request on GitHub. This will send an email to the [V8 node-js team](https://github.com/orgs/v8/teams/node-js). They will review and merge your PR. Once the PR is merged, you can run the CQ for your V8 commit again and land it. If you have specific questions, ping the [V8 node-js team](https://github.com/orgs/v8/teams/node-js) maintainers.
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/node-integration>.
diff --git a/i18n-support.md b/i18n-support.md
index a1eb1c8..7b17377 100644
--- a/i18n-support.md
+++ b/i18n-support.md
@@ -1,44 +1 @@
-# ECMAScript 402
-
-V8 optionally implements the [ECMAScript 402](http://www.ecma-international.org/ecma-402/1.0/) API. The API is enabled by default, but can be turned off at compile time.
-
-
-## Prerequisites
-
-The i18n implementation adds a dependency on ICU. If you run
-
-```
-make dependencies
-```
-
-a suitable version of ICU is checked out into `third_party/icu`.
-
-
-### Alternative ICU checkout
-
-You can check out the ICU sources at a different location and define the gyp variable `icu_gyp_path` to point at the `icu.gyp` file.
-
-
-### System ICU
-
-Last but not least, you can compile V8 against a version of ICU installed in your system. To do so, specify the gyp variable `use_system_icu=1`. If you also have `want_separate_host_toolset` enabled, the bundled ICU will still be compiled to generate the V8 snapshot. The system ICU will only be used for the target architecture.
-
-
-## Embedding V8
-
-If you embed V8 in your application, but your application itself doesn't use ICU, you will need to initialize ICU before calling into V8 by executing:
-
-```
-v8::V8::InitializeICU();
-```
-
-It is safe to invoke this method if ICU was not compiled in, then it does nothing.
-
-
-## Compiling without i18n support
-
-To build V8 without i18n support use
-
-```
-make i18nsupport=off native
-```
\ No newline at end of file
+# This content has moved to <https://v8.dev/docs/i18n>.
