v8/AUTHORS

244 lines
8.6 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>
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>
Andrew Paprocki <andrew@ishiboo.com>
Andrei Kashcha <anvaka@gmail.com>
Anna Henningsen <anna@addaleax.net>
Anton Bikineev <ant.bikineev@gmail.com>
Bangfu Tao <bangfu.tao@samsung.com>
Daniel Shelton <d1.shelton@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>
Brice Dobry <brice.dobry@futurewei.com>
Burcu Dogan <burcujdogan@gmail.com>
Caitlin Potter <caitpotter88@gmail.com>
Chao Wang <chao.w@rioslab.org>
Craig Schlenter <craig.schlenter@gmail.com>
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>
Daniel Andersson <kodandersson@gmail.com>
Daniel Bevenius <daniel.bevenius@gmail.com>
Daniel James <dnljms@gmail.com>
David Carlier <devnexen@gmail.com>
David Manouchehri <david@davidmanouchehri.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 Farolini <domfarolino@gmail.com>
Douglas Crosher <dtc-v8@scieneer.com>
Dusan Milosavljevic <dusan.m.milosavljevic@gmail.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>
Filipe David Manana <fdmanana@gmail.com>
Franziska Hinkelmann <franziska.hinkelmann@gmail.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>
Henrique Ferreiro <henrique.ferreiro@gmail.com>
Hirofumi Mako <mkhrfm@gmail.com>
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>
Jan de Mooij <jandemooij@gmail.com>
Jan Krems <jan.krems@gmail.com>
Janusz Majnert <jmajnert@gmail.com>
Jay Freeman <saurik@saurik.com>
James Pike <g00gle@chilon.net>
James M Snell <jasnell@gmail.com>
Javad Amiri <javad.amiri@anu.edu.au>
Ji Qiu <qiuji@iscas.ac.cn>
Jianghua Yang <jianghua.yjh@alibaba-inc.com>
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>
Junha Park <jpark3@scu.edu>
JunHo Seo <sejunho@gmail.com>
Junming Huang <kiminghjm@gmail.com>
Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Karl Skomski <karl@skomski.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>
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>
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>
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>
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>
Paul Lind <plind44@gmail.com>
Pavel Medvedev <pmedvedev@gmail.com>
PhistucK <phistuck@gmail.com>
Qingyan Li <qingyan.liqy@alibaba-inc.com>
Qiuyi Zhang <qiuyi.zqy@alibaba-inc.com>
Rafal Krypa <rafal@krypa.net>
Raul Tambre <raul@tambre.ee>
Ray Glover <ray@rayglover.net>
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>
Sylvestre Ledru <sledru@mozilla.com>
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>
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>
Wei Wu <lazyparser@gmail.com>
Wenlu Wang <kingwenlu@gmail.com>
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>
Zac Hansen <xaxxon@gmail.com>
Zeynep Cankara <zeynepcankara402@gmail.com>
Zhao Jiazhong <kyslie3100@gmail.com>
Zhongping Wang <kewpie.w.zp@gmail.com>
柳荣一 <admin@web-tinker.com>
Tianping Yang <yangtianping@oppo.com>
Takeshi Yoneda <takeshi@tetrate.io>