v8/AUTHORS

278 lines
9.9 KiB
Plaintext
Raw Normal View History

# Below is a list of people and organizations that have contributed
# to the V8 project. Names should be added to the list like so:
#
# Name/Organization <email address>
Google Inc. <*@google.com>
The Chromium Authors <*@chromium.org>
Sigma Designs Inc. <*@sdesigns.com>
ARM Ltd. <*@arm.com>
Hewlett-Packard Development Company, LP <*@palm.com>
Igalia, S.L. <*@igalia.com>
Joyent, Inc. <*@joyent.com>
Bloomberg Finance L.P. <*@bloomberg.net>
NVIDIA Corporation <*@nvidia.com>
BlackBerry Limited <*@blackberry.com>
Opera Software ASA <*@opera.com>
Intel Corporation <*@intel.com>
LG Electronics, Inc. <*@lge.com>
Microsoft <*@microsoft.com>
MIPS Technologies, Inc. <*@mips.com>
Imagination Technologies, LLC <*@imgtec.com>
Wave Computing, Inc. <*@wavecomp.com>
Loongson Technology Corporation Limited <*@loongson.cn>
Code Aurora Forum <*@codeaurora.org>
Home Jinni Inc. <*@homejinni.com>
IBM Inc. <*@*.ibm.com>
IBM Inc. <*@ibm.com>
Red Hat Inc. <*@redhat.com>
Samsung <*@*.samsung.com>
Samsung <*@samsung.com>
RT-RK Computer Based System <*@rt-rk.com>
Amazon, Inc <*@amazon.com>
ST Microelectronics <*@st.com>
Yandex LLC <*@yandex-team.ru>
StrongLoop, Inc. <*@strongloop.com>
Facebook, Inc. <*@fb.com>
Facebook, Inc. <*@oculus.com>
Vewd Software AS <*@vewd.com>
Groupon <*@groupon.com>
Meteor Development Group <*@meteor.com>
Cloudflare, Inc. <*@cloudflare.com>
Julia Computing, Inc. <*@juliacomputing.com>
CodeWeavers, Inc. <*@codeweavers.com>
Alibaba, Inc. <*@alibaba-inc.com>
Aaron Bieber <deftly@gmail.com>
Aaron O'Mullan <aaron.omullan@gmail.com>
Abdulla Kamar <abdulla.kamar@gmail.com>
Adam Kallai <kadam@inf.u-szeged.hu>
Akinori MUSHA <knu@FreeBSD.org>
Alessandro Pignotti <alessandro@leaningtech.com>
Alex Kodat <akodat@rocketsoftware.com>
Alexander Botero-Lowry <alexbl@FreeBSD.org>
Alexander Karpinsky <homm86@gmail.com>
Alexander Neville <dark@volatile.bz>
Alexandre Vassalotti <avassalotti@gmail.com>
Alexis Campailla <alexis@janeasystems.com>
Allan Sandfeld Jensen <allan.jensen@qt.io>
Amos Lim <eui-sang.lim@samsung.com>
Andreas Anyuru <andreas.anyuru@gmail.com>
Andrei Kashcha <anvaka@gmail.com>
Andrew Paprocki <andrew@ishiboo.com>
Anna Henningsen <anna@addaleax.net>
Antoine du Hamel <duhamelantoine1995@gmail.com>
Anton Bershanskiy <8knots@protonmail.com>
Anton Bikineev <ant.bikineev@gmail.com>
Ao Wang <wangao.james@bytedance.com>
Archil Sharashenidze <achosharashenidze@gmail.com>
Bala Avulapati <bavulapati@gmail.com>
Bangfu Tao <bangfu.tao@samsung.com>
Ben Coe <bencoe@gmail.com>
Ben Newman <ben@meteor.com>
Ben Noordhuis <info@bnoordhuis.nl>
Benjamin Tan <demoneaux@gmail.com>
Bert Belder <bertbelder@gmail.com>
Brendon Tiszka <btiszka@gmail.com>
Brice Dobry <brice.dobry@futurewei.com>
Burcu Dogan <burcujdogan@gmail.com>
Caitlin Potter <caitpotter88@gmail.com>
Chao Wang <chao.w@rioslab.org>
Charles Kerr <charles@charleskerr.com>
Chengzhong Wu <legendecas@gmail.com>
Choongwoo Han <cwhan.tunz@gmail.com>
Chris Nardi <hichris123@gmail.com>
Christopher A. Taylor <chris@gameclosure.com>
Colin Ihrig <cjihrig@gmail.com>
Cong Zuo <zckevinzc@gmail.com>
Craig Schlenter <craig.schlenter@gmail.com>
Daniel Andersson <kodandersson@gmail.com>
Daniel Bevenius <daniel.bevenius@gmail.com>
Daniel Dromboski <dandromb@gmail.com>
Daniel James <dnljms@gmail.com>
Daniel Shelton <d1.shelton@samsung.com>
Danylo Boiko <danielboyko02@gmail.com>
Darshan Sen <raisinten@gmail.com>
David Carlier <devnexen@gmail.com>
David Manouchehri <david@davidmanouchehri.com>
David Sanders <dsanders11@ucsbalum.com>
DISALLOW_IMPLICIT_CONSTRUCTORS for MacroAssembler When BUILDING_V8_SHARED in release builds __declspec(dllexport) causes generation of implicit constructors in the forwarding class while its deleted in TurboAssemblerBase, which leads to compilation errors like: In file included from gen/v8/v8_base_jumbo_6.cc:41: In file included from .\../../v8/src/interface-descriptors.cc:7: In file included from ../../v8\src/macro-assembler.h:40: ../../v8\src/x64/macro-assembler-x64.h(92,9): error: call to deleted constructor of 'v8::internal::TurboAssemblerBase' : TurboAssemblerBase(std::forward<Args>(args)...) {} ^ ~~~~~~~~~~~~~~~~~~~~~~~~ ../../v8\src/x64/macro-assembler-x64.h(536,25): note: in instantiation of function template specialization 'v8::internal::TurboAssembler::TurboAssembler<v8::internal::TurboAssembler>' requested here class V8_EXPORT_PRIVATE MacroAssembler : public TurboAssembler { ^ ../../v8\src/turbo-assembler.h(127,34): note: 'TurboAssemblerBase' has been explicitly marked deleted here DISALLOW_IMPLICIT_CONSTRUCTORS(TurboAssemblerBase); ^ 1 error generated. The original changes were made in https://chromium-review.googlesource.com/c/v8/v8/+/1414913 R=mstarzinger@chromium.org,jgruber@chromium.org,clemensh@chromium.org Bug: NONE Change-Id: I87a5a678b8bae13b3adc6f1c6ac0b9313ed18d85 Reviewed-on: https://chromium-review.googlesource.com/c/1454676 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59427}
2019-02-06 11:09:34 +00:00
Deepak Mohan <hop2deep@gmail.com>
Deon Dior <diaoyuanjie@gmail.com>
Derek Tu <derek.t@rioslab.org>
Dominic Chen <d.c.ddcc@gmail.com>
Dominic Farolini <domfarolino@gmail.com>
Douglas Crosher <dtc-v8@scieneer.com>
Dusan Milosavljevic <dusan.m.milosavljevic@gmail.com>
Eden Wang <nedenwang@tencent.com>
[cpu-profile] Timestamps in tracing events args stay in monotonic time On Linux, Perfetto translates the builtin "ts" timestamp in trace event from CLOCK_MONOTONIC to CLOCK_BOOTTIME, before passing them to devtools. Devtools therefore implicitly operates on timestamps that are in CLOCK_BOOTTIME. However, additional timestamps sent in trace event payload arguments will not be converted to CLOCK_BOOTTIME by Perfetto, raising the possibility of devtools using timestamps from multiple clock domains incorrectly. Since trace events sent by CpuProfile also include the builtin "ts" trace timestamp (sampled from CLOCK_MONOTONIC nearly at the same time by the tracing framework), sending "data.startTime" and "data.endTime" is essentially redundant. devtools-frontend:2113957 stops the use of the value of these timestamps in the payload of Profile and ProfileChunk events. Devtools continue to use the presence of these arguments to indentify start and end profile events. ProfileChunk events also include "timeDeltas" which are relative timestamps. They are also in CLOCK_MONOTONIC and are not translated by Perfetto. devtools-frontend:2113957 computes absolute CLOCK_BOOTTIME timestamps from timeDeltas by adding them to "ts" in the "Profile" event (previously, "data.startTime" was used). This is only valid if the system is not suspended/resumed during profiling. Providing support for suspend/resume in the middle of profiling will likely involve having Perfetto convert "timeDeltas" directly to CLOCK_BOOTTIME. This CL introduces no code changes and only adds comments to explain the above. BUG=chromium:1055871 Change-Id: I649dfcce8ea1a100c0ecfe03f843c7cb1fdd6f33 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2114001 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#66820}
2020-03-21 06:49:03 +00:00
Eric Rannaud <eric.rannaud@gmail.com>
Erich Ocean <erich.ocean@me.com>
Evan Lucas <evan.lucas@help.com>
Fedor Indutny <fedor@indutny.com>
Felix Geisendörfer <haimuiba@gmail.com>
Feng Yu <f3n67u@gmail.com>
Filipe David Manana <fdmanana@gmail.com>
Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Gao Sheng <gaosheng08@meituan.com>
Geoffrey Garside <ggarside@gmail.com>
Gergely Nagy <ngg@ngg.hu>
Gilang Mentari Hamidy <gilang@hamidy.net>
Gus Caplan <me@gus.host>
Gwang Yoon Hwang <ryumiel@company100.net>
Haichuan Wang <hc.opensource@gmail.com>
Re-detect the host time zone if requested by an embedder Add an enum argument to DateTimeConfigurationChangeNotification to control whether or not to redetect the host time zone. The default value kSkip doesn't cause redetecting so that callers do not need to change if they want the current behavior (e.g. Chromium). Note that the host time zone detection does not work when v8 is run inside a sandbox as in Chromium so that Chromium detects the host time zone outside the sandbox before calling DateTimeConfigurationChangeNotification. OTOH, other v8 embedders may find it more convenient for v8 to do the host time zone detection on their behalf. In that case, they can call the function with the new argument set to value kRedetect. Test: With PHP+V8Js on linux, execute: php -r ' putenv("TZ=Europe/Helsinki"); $v8 = new V8Js(); $v8->executeString("print((new Date(0)).toString()+\"\\n\");"); putenv("TZ=America/New_York"); $v8->executeString("print((new Date(0)).toString()+\"\\n\");");' Result before modification: Thu Jan 01 1970 02:00:00 GMT+0200 (Eastern European Standard Time) Thu Jan 01 1970 02:00:00 GMT+0200 (Eastern European Standard Time) Result after modification: Thu Jan 01 1970 02:00:00 GMT+0200 (Eastern European Standard Time) Thu Jan 01 1970 02:00:00 GMT+0200 (Eastern European Standard Time) Result after V8JS is modified to use value kRedetect when calling Thu Jan 01 1970 02:00:00 GMT+0200 (Eastern European Standard Time) Wed Dec 31 1969 19:00:00 GMT-0500 (Eastern Standard Time) DateTimeConfigurationChangeNotification: Change-Id: I005192dd42669a94f606a49baa9eafad3475b9fd Reviewed-on: https://chromium-review.googlesource.com/c/1449637 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jungshik Shin <jshin@chromium.org> Commit-Queue: Jungshik Shin <jshin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59613}
2019-02-13 23:27:41 +00:00
Hannu Trey <hannu.trey@gmail.com>
Harshal Nandigramwar <pro.bbcom18@gmail.com>
Harshil Jain <twitharshil@gmail.com>
Henrique Ferreiro <henrique.ferreiro@gmail.com>
Hirofumi Mako <mkhrfm@gmail.com>
Hisham Muhammad <hisham@gobolinux.org>
Honggyu Kim <honggyu.kp@gmail.com>
Huáng Jùnliàng <jlhwung@gmail.com>
HyeockJin Kim <kherootz@gmail.com>
[regexp] Fix and unify non-unicode case-folding algorithms Non-unicode, case-insensitive regexps (e.g. /foo/i, not foo/iu) use a case-folding algorithm that doesn't quite match the Unicode definition. There are two places in irregexp that need to do case-folding. Prior to this patch, neither of them quite matched the spec (https://tc39.es/ecma262/#sec-runtime-semantics-canonicalize-ch). This patch implements the "Canonicalize" algorithm in src/regexp/special-case.h, and uses it in the relevant places. It replaces special-case logic around upper-casing / ASCII characters with the following approach: 1. For most characters, calling UnicodeSet::closeOver on a set containing that character will produce the correct set of case-insensitive matches. 2. For a small handful of characters (like the sharp S that prompted this change), UnicodeSet::closeOver will include some characters that should be omitted. For example, although closeOver('ß') = "ßẞ", uppercase('ß') is "SS", so step 3.e means that 'ß' canonicalizes to itself, and should not match 'ẞ'. In these cases, we can skip the closeOver entirely, because it will never add an equivalent character. These characters are in the IgnoreSet. 3. For an even smaller handful of characters, UnicodeSet::closeOver will produce some characters that should be omitted, but also some characters that should be included. For example, closeOver('k') = "kKK" (lowercase k, uppercase K, U+212A KELVIN SIGN), but KELVIN SIGN should not match either of the other two (step 3.g). To handle this, we put such characters in the SpecialAddSet. In these cases, we closeOver the original character, but filter out the results that do not have the same canonical value. The computation of IgnoreSet and SpecialAddSet happens at build time, using the pre-existing gen-regexp-special-case.cc step. R=jgruber@chromium.org Bug: v8:10248 Change-Id: I00d48b180c83bb8e645cc59eda57b01eab134f0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072858 Reviewed-by: Frank Tang <ftang@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66641}
2020-03-03 21:58:46 +00:00
Iain Ireland <iireland@mozilla.com>
Ingvar Stepanyan <me@rreverser.com>
Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com>
Isiah Meadows <impinball@gmail.com>
Jaime Bernardo <jaime@janeasystems.com>
James M Snell <jasnell@gmail.com>
James Pike <g00gle@chilon.net>
Jan Krems <jan.krems@gmail.com>
Jan de Mooij <jandemooij@gmail.com>
Janusz Majnert <jmajnert@gmail.com>
Javad Amiri <javad.amiri@anu.edu.au>
Jay Freeman <saurik@saurik.com>
Jesper van den Ende <jespertheend@gmail.com>
Ji Qiu <qiuji@iscas.ac.cn>
Jiawen Geng <technicalcute@gmail.com>
Jiaxun Yang <jiaxun.yang@flygoat.com>
Joel Stanley <joel@jms.id.au>
Johan Bergström <johan@bergstroem.nu>
Jonathan Liu <net147@gmail.com>
Julien Brianceau <jbriance@cisco.com>
JunHo Seo <sejunho@gmail.com>
Junha Park <jpark3@scu.edu>
Junming Huang <kiminghjm@gmail.com>
Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Karl Skomski <karl@skomski.com>
Keith Smiley <keithbsmiley@gmail.com>
Kevin Gibbons <bakkot@gmail.com>
Kris Selden <kris.selden@gmail.com>
Kyounga Ra <kyounga@alticast.com>
Loo Rong Jie <loorongjie@gmail.com>
Lu Yahan <yahan@iscas.ac.cn>
Luis Reis <luis.m.reis@gmail.com>
Luke Zarko <lukezarko@gmail.com>
Ma Aiguo <maaiguo@uniontech.com>
Maciej Małecki <me@mmalecki.com>
Marcel Laverdet <marcel@laverdet.com>
Marcin Cieślak <saper@marcincieslak.com>
Marcin Wiącek <marcin@mwiacek.com>
Martin Bidlingmaier <martin.bidlingmaier@gmail.com>
Mateusz Czeladka <mateusz.szczap@gmail.com>
Matheus Marchini <mat@mmarchini.me>
Matheus Marchini <mmarchini@netflix.com>
Mathias Bynens <mathias@qiwi.be>
Matt Hanselman <mjhanselman@gmail.com>
Matthew Sporleder <msporleder@gmail.com>
Maxim Mazurok <maxim@mazurok.com>
Maxim Mossienko <maxim.mossienko@gmail.com>
Michael Lutz <michi@icosahedron.de>
Michael Mclaughlin <m8ch88l@gmail.com>
Michael Smith <mike@w3.org>
Michaël Zasso <mic.besace@gmail.com>
Mihir Shah <mihirshah.11204@gmail.com>
Mike Gilbert <floppymaster@gmail.com>
Mike Pennisi <mike@mikepennisi.com>
Mikhail Gusarov <dottedmag@dottedmag.net>
Milton Chiang <milton.chiang@mediatek.com>
Mu Tao <pamilty@gmail.com>
Myeong-bo Shim <m0609.shim@samsung.com>
Nicolas Antonius Ernst Leopold Maria Kaiser <nikai@nikai.net>
[class] Improve errors for reinitialized private elements Previously V8 was reusing the error fur duplicate declarations, using the private name for class fields or the class name for class methods as the redeclared identifier. class A { constructor(o) { return o } } class B extends A { #x } class C extends A { #x() {} } let D = (0, class extends A { #x() {} }); new B(new B({})) // Identifier '#x' has already been declared new C(new C({})) // Identifier 'C' has already been declared new D(new D({})) // Identifier '' has already been declared This patch changes it to use error messages that better explain what's happening: new B(new B({})) // Cannot initialize #x twice on the same object new C(new C({})) // Cannot initialize private methods of // class C twice on the same object new D(new D({})) // Cannot initialize private methods of // class anonymous twice on the same object I initially tried to use the same message for both fields and methods, but the problem with that is that when initializing fields we only have access to the field name, while when initializing methods we only have access to the class name (using the "private brand" symbol). However, almost all the error messages are different for private fields and for methods so this shouldn't be a problem. Bug: v8:12042 Change-Id: Iaa50c16e4fa5c0646ad9ef2aa7e65bb649b3fce2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3078362 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Joyee Cheung <joyee@igalia.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#76279}
2021-08-11 14:32:58 +00:00
Nicolò Ribaudo <nicolo.ribaudo@gmail.com>
Niek van der Maas <mail@niekvandermaas.nl>
Niklas Hambüchen <mail@nh2.me>
Noj Vek <nojvek@gmail.com>
Oleksandr Chekhovskyi <oleksandr.chekhovskyi@gmail.com>
Oliver Dunk <oliver@oliverdunk.com>
Paolo Giarrusso <p.giarrusso@gmail.com>
Patrick Gansterer <paroga@paroga.com>
Paul Lind <plind44@gmail.com>
Pavel Medvedev <pmedvedev@gmail.com>
Peng Fei <pfgenyun@gmail.com>
Peng Wu <peng.w@rioslab.org>
Peng-Yu Chen <pengyu@libstarrify.so>
Peter Rybin <peter.rybin@gmail.com>
Peter Varga <pvarga@inf.u-szeged.hu>
Peter Wong <peter.wm.wong@gmail.com>
PhistucK <phistuck@gmail.com>
Rafal Krypa <rafal@krypa.net>
Raul Tambre <raul@tambre.ee>
Ray Glover <ray@rayglover.net>
Ray Wang <ray@isrc.iscas.ac.cn>
Refael Ackermann <refack@gmail.com>
Rene Rebe <rene@exactcode.de>
Reza Yazdani <ryazdani@futurewei.com>
Rick Waldron <waldron.rick@gmail.com>
Rob Wu <rob@robwu.nl>
Robert Meijer <robert.s.meijer@gmail.com>
Robert Mustacchi <rm@fingolfin.org>
Robert Nagy <robert.nagy@gmail.com>
Robert O'Callahan <rocallahan@gmail.com>
Rong Wang <wangrong089@gmail.com>
Ross Kirsling <rkirsling@gmail.com>
Ruben Bridgewater <ruben@bridgewater.de>
Ryan Dahl <ry@tinyclouds.org>
Sakthipriyan Vairamani (thefourtheye) <thechargingvolcano@gmail.com>
Sander Mathijs van Veen <sander@leaningtech.com>
Sandro Santilli <strk@keybit.net>
Sanjoy Das <sanjoy@playingwithpointers.com>
Seo Sanghyeon <sanxiyn@gmail.com>
Shawn Anastasio <shawnanastasio@gmail.com>
Shawn Presser <shawnpresser@gmail.com>
Stefan Penner <stefan.penner@gmail.com>
Stephan Hartmann <stha09@googlemail.com>
Reland "[api] JSFunction PromiseHook for v8::Context" This is a reland of d5457f5fb7ea05ca05a697599ffa50d35c1ae3c7 after a speculative revert. Additionally it fixes an issue with throwing promise hooks. Original change's description: > [api] JSFunction PromiseHook for v8::Context > > This will enable Node.js to get much better performance from async_hooks > as currently PromiseHook delegates to C++ for the hook function and then > Node.js delegates it right back to JavaScript, introducing several > unnecessary barrier hops in code that gets called very, very frequently > in modern, promise-heavy applications. > > This API mirrors the form of the original C++ function based PromiseHook > API, however it is intentionally separate to allow it to use JSFunctions > triggered within generated code to, as much as possible, avoid entering > runtime functions entirely. > > Because PromiseHook has internal use also, beyond just the Node.js use, > I have opted to leave the existing API intact and keep this separate to > avoid conflicting with any possible behaviour expectations of other API > users. > > The design ideas for this new API stemmed from discussion with some V8 > team members at a previous Node.js Diagnostics Summit hosted by Google > in Munich, and the relevant documentation of the discussion can be found > here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e > > A summary of the reasons for why this new design is important can be > found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing > > Bug: v8:11025 > Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Anton Bikineev <bikineev@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73858} Bug: v8:11025 Bug: chromium:1197475 Change-Id: I73a71e97d9c3dff89a2b092c3fe4adff81ede8ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2823917 Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Anton Bikineev <bikineev@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74071}
2021-04-14 22:44:39 +00:00
Stephen Belanger <stephen.belanger@datadoghq.com>
Sylvestre Ledru <sledru@mozilla.com>
Takeshi Yoneda <takeshi@tetrate.io>
Taketoshi Aono <brn@b6n.ch>
Tao Liqiang <taolq@outlook.com>
Teddy Katz <teddy.katz@gmail.com>
Thomas Young <wenzhang5800@gmail.com>
Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Tianping Yang <yangtianping@oppo.com>
Timo Teräs <timo.teras@iki.fi>
Tobias Burnus <burnus@net-b.de>
Tobias Nießen <tniessen@tnie.de>
Ujjwal Sharma <usharma1998@gmail.com>
Vadim Gorbachev <bmsdave@gmail.com>
Varun Varada <varuncvarada@gmail.com>
Victor Costan <costan@gmail.com>
Vlad Burlik <vladbph@gmail.com>
Vladimir Krivosheev <develar@gmail.com>
Vladimir Shutoff <vovan@shutoff.ru>
Wael Almattar <waelsy123@gmail.com>
Wei Wu <lazyparser@gmail.com>
Wenlu Wang <kingwenlu@gmail.com>
Wenming Yang <yangwenming@bytedance.com>
Allowing map word to be used for other state in GC header. This CL adds features to pack/unpack map words. Currently V8 cannot store extra metadata in object headers -- because V8 objects do not have a proper header, but only a map pointer at the start of the object. To store per-object metadata like marking data, a side table is required as the per-object metadata storage. This CL enables V8 to use higher unused bits in a 64-bit map word as per-object metadata storage. Map pointer stores come with an extra step to encode the metadata into the pointer (we call it "map packing"). Map pointer loads will also remove the metadata bits as well (we call it "map packing"). Since the map word is no longer a valid pointer after packing, we also change the tag of the packed map word to make it looks like a Smi. This helps various GC and barrier code to correctly skip them instead of blindly dereferencing this invalid pointer. A ninja flag `v8_enable_map_packing` is provided to turn this map-packing feature on and off. It is disabled by default. * Only works on x64 platform, with `v8_enable_pointer_compression` set to `false` Bug: v8:11624 Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#73915}
2021-04-06 12:01:44 +00:00
Wenyu Zhao <wenyu.zhao@anu.edu.au>
Wiktor Garbacz <wiktor.garbacz@gmail.com>
Wouter Vermeiren <wouter.vermeiren@essensium.com>
Xiaofang Zou <zouxiaofang@iscas.ac.cn>
Xiaoyin Liu <xiaoyin.l@outlook.com>
Yanbo Li <lybvinci@gmail.com>
Yannic Bonenberger <contact@yannic-bonenberger.com>
Yi Wang <wangyi8848@gmail.com>
Yong Wang <ccyongwang@tencent.com>
Youfeng Hao <ajihyf@gmail.com>
Yu Yin <xwafish@gmail.com>
Yujie Wang <hex6770@gmail.com>
Yuri Iozzelli <yuri@leaningtech.com>
Yusif Khudhur <yusif.khudhur@gmail.com>
Yuxiang Cao <caoyxsh@outlook.com>
Zac Hansen <xaxxon@gmail.com>
Zeynep Cankara <zeynepcankara402@gmail.com>
Zhao Jiazhong <kyslie3100@gmail.com>
Zheng Liu <i6122f@gmail.com>
Zhongping Wang <kewpie.w.zp@gmail.com>
柳荣一 <admin@web-tinker.com>
Yang Xiang <xiangyangemail@gmail.com>