- 11 Feb, 2021 1 commit
-
-
Santiago Aboy Solanes authored
Reasons: * We disabled it more than a year ago for all configs * Not easy to re-enable * Not compatible with pointer compression as-is * Not compatible with concurrent TP/TF as-is * No concrete plans to re-enable it Also remove Map's layout_descriptor since it was only used for double field unboxing. Bug: v8:11422 Change-Id: I9260906eac199213b3210712e9903f1ecf1d7979 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676637Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72671}
-
- 25 Nov, 2020 1 commit
-
-
Zhi An Ng authored
Also remove a comment referring to using the macro. Bug: v8:11074 Change-Id: Ib56a0360b28812833b372738f4956ef41c59a97b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557058Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71388}
-
- 24 Nov, 2020 1 commit
-
-
Georg Neis authored
Apart from removing Min and Max (utils.h), this is mostly a renaming. In a few cases I had to add a cast. In a bunch of cases I had to use initializer lists to force call-by-value for static member constants because call-by-reference wouldn't compile (like in the previous CL). In a few places I used initializer lists in place of nested min/max operations. Bug: v8:11074 Change-Id: I53a5411be6334ff41e7a8517e6b87fb46f14d086 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2545523 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#71380}
-
- 20 Nov, 2020 1 commit
-
-
Leszek Swirski authored
Because of LocalHeap safepoints, our existing assert scopes don't necessarily maintain the same guarantees as desired. In particular, DisallowHeapAllocation no longer guarantees that objects don't move. This patch transitions DisallowHeapAllocation to DisallowGarbageCollection, to ensure that code using this scope is also protected against safepoints. Change-Id: I0411425884f6849982611205fb17bb072881c722 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71319}
-
- 11 Nov, 2020 1 commit
-
-
Igor Sheludko authored
This CL * renames Name::hash_field field to raw_hash_field. * all local variables that store raw_hash_field value are also renamed to raw_hash_field where possible. Bug: chromium:1133527, v8:11074 Change-Id: I17313f386110b33a64f629cc2b9d4afd1e06c6c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2471999Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71114}
-
- 21 Oct, 2020 1 commit
-
-
Shu-yu Guo authored
Implements https://github.com/tc39/ecma262/pull/2154, which allows module export names to be string literals. Semantics highlights: - It is a SyntaxError for string literal export names to have unpaired UTF16 surrogates. - It is a SyntaxError for string literal export names to be used as the local name without being followed by a 'from' clause. For example, `export { "foo" }` and `export { "foo" as "bar" }` are errors, but `export { "foo" } from "./module.js"` is allowed. The remaining failing test262 test is wrong: https://github.com/tc39/test262/issues/2866 Bug: v8:10964 Change-Id: Ib3e06e1ee6b3f1b60ed7f24e21902e17ddfc0351 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2482335 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#70692}
-
- 20 Oct, 2020 1 commit
-
-
Edward Lesmes authored
Generate DIR_METADATA files and remove metadata from OWNERS files for v8. R=jkummerow@chromium.org, ochang@chromium.org, yangguo@chromium.org Bug: chromium:1113033 Change-Id: I82cbb62e438d82dbbc408e87120af39fa9da0afa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476680Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org> Auto-Submit: Edward Lesmes <ehmaldonado@chromium.org> Cr-Commit-Position: refs/heads/master@{#70669}
-
- 05 Oct, 2020 1 commit
-
-
Santiago Aboy Solanes authored
We can use tag dispatching to distinguish between the synchronized and non-synchronized accessors. Also eliminated the need of adding explicit "synchronized" in the name when using the macros. As a note, we currently have one case of using both relaxed and synchronized accessors (Map::instance_descriptors). Cleaned up: * BytecodeArray::source_position_table * Code::code_data_container * Code::source_position_table * FunctionTemplateInfo::call_code * Map::instance_descriptors * Map::layout_descriptor * SharedFunctionInfo::function_data Bug: v8:7790 Change-Id: I5a502f4b2df6addb6c45056e77061271012c7d90 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424130 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70306}
-
- 02 Oct, 2020 1 commit
-
-
Toon Verwaest authored
Using a OneByte table allows branches to be removed if the function is inlined in a place where we statically know the character is onebyte. This adds support for line terminators. To support 2byte line terminators as well this adds a entries for the lower byte into the table so we can often take a faster path in that case as well. Change-Id: Ibd08d540e0e13047d6c1f675c187f14fda4336c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445471Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#70286}
-
- 23 Sep, 2020 1 commit
-
-
Leszek Swirski authored
We currently have a pattern of setting a dereferenced Handle location to update that Handle's value: *handle.location() = new_value.ptr() This is slightly opaque, and definitely not type-safe, so add a new Handle<T>::PatchValue method which does this operation. Ideally we would make Handle::location() return a const pointer to discourage this sort of use, but there's a bunch of places where that location pointer is used and passed around as a Handle surrogate, so those would have to be updated first. Change-Id: I157f7e2473ed1b86f7a93cae260b0932fed0ad88 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424249 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70088}
-
- 21 Sep, 2020 1 commit
-
-
Martin Bidlingmaier authored
Assertions are implemented with the new ASSERTION instruction. The nfa interpreter evaluates the assertion based on the current context in the subject string every time a thread executes ASSERTION. This is analogous to what re2 and rust/regex do. Alternatives to this approach: - The interpreter could calculate eagerly for all assertion types whether they are satisfied whenever the current input position is advanced. This would make evaluating the ASSERTION instruction itself cheaper, but at the cost of making every advance in the input string more expensive. I suspect this would be slower on average because assertions are not that common that we typically evaluate >= 2 assertions at every input position. - Assertions in a regexp could be desugared into CONSUME_RANGE instructions, so that no new instruction would be necessary. For example, the word boundary assertion \b is satisfied at a given position/state if we have just consumed a word character and will consume a non-word character next, or vice-versa. The tricky part about this is that the assertion itself should not consume input, so we'd have to split (automaton) states according to whether we've arrived at them via a word character or not. The current compiler is not really equipped for this kind of transformation. For {start,end} of {line,file} assertions, we'd need to introduce dummy characters indicating start/end of input (say, 0x10000 and 0x10001) which we feed to the interpreter before respectively after the actual input. I suspect that this approach wouldn't make much of a difference for NFA execution. It would likely speed up (lazy) DFA execution though because assertions would be dealt with in the fast path. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:10765 Change-Id: Ic2012c943e0ce54eb8662789fb3d4c1b6cd8d606 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398644 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70026}
-
- 07 Sep, 2020 1 commit
-
-
Camillo Bruni authored
memchr is used in the default case but for two-byte strings that contain mostly ascii sequences every other byte is 0. This CL special-cases the 0 byte search in a two-byte string to simply peform a simple for loop which is rouhly 10x faster than the repeated memchr approach. Bug: v8:10737 Change-Id: Icde6b858b6679da69448295616734c46aa95e439 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364507Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#69721}
-
- 17 Aug, 2020 1 commit
-
-
Jakob Kummerow authored
This is a comment-only CL. Change-Id: I002b1765bfa839982ab11c22f744734fdd34d4ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352788Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#69417}
-
- 20 Jul, 2020 1 commit
-
-
Etienne Pierre-Doray authored
This reverts commit d1aee56d. Reason for revert: Trace event is causing telemetry regressions (crbug.com/1094957). I got a few days of traces and didn't really find what I was looking for, so I'll find another way to investigate. Original change's description: > [Jank]: Add uri trace events > > To investigate jank found in UMA sampling profiler. > > Bug: chromium:1081433 > Change-Id: I457731380505af5a4d7a0c30d01b4049ffd2b436 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2242037 > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68326} TBR=leszeks@chromium.org,etiennep@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:1081433, chromium:1094957 Change-Id: I6c9573e9a77a54255c5fadc3cec14d437fd62b45 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2279135 Auto-Submit: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#68949}
-
- 12 Jun, 2020 1 commit
-
-
Etienne Pierre-doray authored
To investigate jank found in UMA sampling profiler. Bug: chromium:1081433 Change-Id: I457731380505af5a4d7a0c30d01b4049ffd2b436 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2242037 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#68326}
-
- 29 Apr, 2020 2 commits
-
-
Ben Smith authored
This reverts commit 908f08e4. Reason for revert: Seems like it may be causing v8-fuzzer failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Fuzzer/36017 Original change's description: > [ast] Remove literal allocation from CallPrinter > > Access literal data directly in CallPrinter, rather than allocating > their values. This allows us to remove the isolate member from > CallPrinter entirely. > > Change-Id: Ib4203009c86b6778ee843e8956fc7cee2214841e > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122019 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67471} TBR=leszeks@chromium.org,verwaest@chromium.org Change-Id: Ia7e0c95ee6ec58e5067d92c7517269fd334041a1 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2171929Reviewed-by: Ben Smith <binji@chromium.org> Commit-Queue: Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#67480}
-
Leszek Swirski authored
Access literal data directly in CallPrinter, rather than allocating their values. This allows us to remove the isolate member from CallPrinter entirely. Change-Id: Ib4203009c86b6778ee843e8956fc7cee2214841e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122019Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67471}
-
- 17 Apr, 2020 1 commit
-
-
Clemens Backes authored
{StaticCharVector}, according to its name, should return a {Vector<const char>}. For getting a {Vector<const uint8_t>}, the method should be called {StaticOneByteVector}, analog to the {OneByteVector} methods that already exist. Also, {StaticCharVector} is constexpr, but {StaticOneByteVector} cannot be, since it contains a {reinterpret_cast}. The same holds for {Vector::cast} in general. This CL - changes the return type of {StaticCharVector} to be {Vector<const char>}, - introduces a new {StaticOneByteVector} which returns {Vector<const uint8_t>}, - fixes constexpr annotations at various methods returning {Vector}s, - refactors users of {StaticCharVector} to either use {StaticOneByteVector} instead, or work on {char} if that makes more sense. R=leszeks@chromium.org Bug: v8:10426 Change-Id: I71e336097e41ad30f982aa6344ca3d67b3a01fe3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154196 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67213}
-
- 17 Feb, 2020 1 commit
-
-
Jakob Kummerow authored
By replacing usage of the IsNotArrayIndex bit with IsNotIntegerIndex, we get back one bit that we can use to increase the number of hash bits stored. The price is that strings that represent array/integer indices beyond the cacheable range will have to be scanned more often, but these strings should be rare, and we expect that the additional hash bit is more worthwhile to have. Bug: v8:9904 Change-Id: I33f74b0a73f4754aee85805d4b7c409177668439 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051947Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66299}
-
- 16 Jan, 2020 1 commit
-
-
Bill Ticehurst authored
Add the necessary V8_EXPORT_PRIVATE attributes and a few other minor changes to make building DLLs with MSVC happy. (Note: Debug builds still seem to be failing in Torque, but this fixes Release builds). Bug: v8:8791 Change-Id: Ia4d5372fd1cb961e6268a2b5c089bcd17822f1e5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1996157Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65822}
-
- 25 Nov, 2019 3 commits
-
-
Jakob Kummerow authored
This is a reland of e1ad9b89 Original change's description: > Fixes for size_t LookupIterator > > Fixing some fallout from c968607e > aka r65078 > > Bug: chromium:1026729,chromium:1026856,chromium:1026909,chromium:1026974 > Change-Id: I98a4466595fbf1635af403ab58842977882c0453 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930907 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65158} Tbr: verwaest@chromium.org,mstarzinger@chromium.org Bug: chromium:1026729, chromium:1026856, chromium:1026909, chromium:1026974 Change-Id: I66695f05c4910c46f3c75209e14135075721f2cf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932839Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65162}
-
Shu-yu Guo authored
This reverts commit e1ad9b89. Reason for revert: Landed test that fails with GC stress Original change's description: > Fixes for size_t LookupIterator > > Fixing some fallout from c968607e > aka r65078 > > Bug: chromium:1026729,chromium:1026856,chromium:1026909,chromium:1026974 > Change-Id: I98a4466595fbf1635af403ab58842977882c0453 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930907 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65158} TBR=jkummerow@chromium.org,mstarzinger@chromium.org,verwaest@chromium.org Change-Id: I1f1e95d37b033e53330adae08071cbe34e1d9488 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1026729, chromium:1026856, chromium:1026909, chromium:1026974 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1933599Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#65159}
-
Jakob Kummerow authored
Fixing some fallout from c968607e aka r65078 Bug: chromium:1026729,chromium:1026856,chromium:1026909,chromium:1026974 Change-Id: I98a4466595fbf1635af403ab58842977882c0453 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930907 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65158}
-
- 22 Nov, 2019 1 commit
-
-
Clemens Backes authored
A previous CL (https://crrev.com/c/1926769) changed hashing to always treat the input as signed values. This causes problems, since the hash of a one-byte string differs the hash of the identical two-byte string. Hence this CL switches to treating all values as unsigned in hashing. The bug cannot easily be reproduced in v8 alone, since we would need to create an internalized two-byte string, which contains one-byte data. Blink manages to create such a string via external strings. R=jkummerow@chromium.org Bug: chromium:1025184, chromium:1027131 Change-Id: Id41aa0e463691c02099a08c6e9d837a079c872df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930615Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65113}
-
- 21 Nov, 2019 1 commit
-
-
Clemens Backes authored
Hashing should ignore the signedness of the type, since different platforms might define standard types like {char} as either signed or unsigned. This leads to problems if hashes are included in test expectations, see https://crrev.com/c/1926032 and https://crbug.com/1025184#c26. This CL avoid such problems by always treating the input as signed values. This also reduces binary size, since the instantiations for int8_t and uint8_t are identical now and are folded together by the compiler / linker. R=jkummerow@chromium.org Bug: chromium:1025184 Change-Id: I3fee4d8662dd1c31cd6483639fe4edd4511662c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926769Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65090}
-
- 18 Nov, 2019 1 commit
-
-
Jakob Kummerow authored
This is a reland of 556f44c4 Original change's description: > [strings] Fix hash for exactly 512MB long strings > > Bug: chromium:1016237 > Change-Id: Idda1e44b5d578d1213aa54927ca68289bcdce8ac > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878487 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64552} Bug: chromium:1016237 Change-Id: I92ff4da0b25877faddfd171105b77680f9e08037 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1918251Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65019}
-
- 15 Nov, 2019 1 commit
-
-
Dan Elphick authored
utils.h itself is fairly large and contains lots of unrelated functions as well as having a fair number of dependencies itself, so this splits bounds checking and bit field operations into their own headers in base and replaces uses of utils.h with the more appropriate header where possible. (Also fixes some cases where other headers were previously brought in transitively). Bug: v8:9810, v8:8912 Change-Id: I76c53f953848a57e2c5bfad6ce45abcd6d2a4f1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916604Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64983}
-
- 31 Oct, 2019 1 commit
-
-
Yang Guo authored
R=hpayer@chromium.org Change-Id: If3586bf451e08ab4bbf6d91b9f15382fad411219 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868609 Auto-Submit: Yang Guo <yangguo@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#64679}
-
- 24 Oct, 2019 2 commits
-
-
Shu-yu Guo authored
This reverts commit 556f44c4. Reason for revert: Test fatally OOMs on ARM. https://ci.chromium.org/p/v8/builders/ci/V8%20Arm/12336 Original change's description: > [strings] Fix hash for exactly 512MB long strings > > Bug: chromium:1016237 > Change-Id: Idda1e44b5d578d1213aa54927ca68289bcdce8ac > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878487 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64552} TBR=jkummerow@chromium.org,ishell@chromium.org Change-Id: Ia942469346b0f11fcf853d21717fd127815f7fba No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1016237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879669Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#64553}
-
Jakob Kummerow authored
Bug: chromium:1016237 Change-Id: Idda1e44b5d578d1213aa54927ca68289bcdce8ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878487 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#64552}
-
- 22 Oct, 2019 1 commit
-
-
lybvinci authored
When is_component_build is true, cctest will compile error, because the dependencies is not exported.these files will failed:test-utils -arm64.cc,test-strings.cc. Change-Id: I4bcdde08199f21454ec6d7e230d9d096c0315eac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873447Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#64448}
-
- 15 Oct, 2019 1 commit
-
-
Igor Sheludko authored
... which broke with 32-bit Smis. Tbr: verwaest@chromium.org No-Tree-Checks: true Bug: v8:9767 Change-Id: I459a5d807d87012ab72138f46b49362f16b6baa1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862562Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#64289}
-
- 11 Oct, 2019 1 commit
-
-
Jakob Kummerow authored
This is for consistency and compiler-enforced type safety. No change in behavior intended. Change-Id: I31467832ba6c63fd5f97df9fee6221559b283d67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852766 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64244}
-
- 08 Oct, 2019 1 commit
-
-
Jakob Kummerow authored
This is useful for the upcoming "huge TypedArrays" support, to be able to quickly decide in stubs/generated code whether a string used as the key for a property load/store can possibly be an exotic integer index. Bug: v8:4153 Change-Id: I50ce655d2f78fb36e5615fd580f22c9290216c84 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1821460 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#64165}
-
- 18 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
This is an unmodified reland of 60624b56. Nosnap bots do not block LKGR any more: https://crbug.com/v8/9737#c10. Original change's description: > Disallow nullptr arguments for {CopyChars} > > This allows to remove special casing for the {count == 0} case, which > was needed because {memmove} does not accept {nullptr} arguments even > if the {count} is zero. > > R=leszeks@chromium.org > > Bug: v8:9396 > Change-Id: Iaef3cdbbffa74c2ba1c4e4501dafd943282cbcd9 > Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807366 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63838} TBR=leszeks@chromium.org Bug: v8:9396 Change-Id: I6ab13575f13df060b450ff105e4b9db516671dcf Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809365Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63863}
-
- 17 Sep, 2019 2 commits
-
-
Adam Klein authored
This reverts commits 9febc505 (along with followup commit 60624b56). Reason for revert: Breaks win32 nosnap shared, blocking lkgr & roll: https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/35145 nosnap bots may be deprecated, but as long as they're in LKGR we need to mind them. Original change's description: > Reland "Remove all custom CopyCharsUnsigned implementations" > > This is a reland of 5d8c4890 > > Original change's description: > > Remove all custom CopyCharsUnsigned implementations > > > > It's unclear whether the custom implementation have any advantage over > > the standard library one's. > > Since we update our toolchain and standard library regularly, it might > > well be the case that the custom implementations are slower by now. > > > > Thus this CL removes all {CopyCharsUnsigned} implementations and > > implements {CopyChars} generically using {std::copy_n}. > > > > Note that this does not touch the {MemMove} and {MemCopy} functions > > yet, as we have seen regressions when trying to remove them before > > (https://crbug.com/v8/8675#c5). > > > > R=leszeks@chromium.org > > > > Bug: v8:9396 > > Change-Id: I97a183afebcccd2fbb567bdba02e827331475608 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577 > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#63808} > > Bug: v8:9396 > Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng > Change-Id: I9cd754ebe6b802bb4aabd6d2a448de41da040874 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807357 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63823} TBR=leszeks@chromium.org,clemensh@chromium.org Change-Id: Ic53ab2293d5dc7722a1121d1aa1159328a6ed8f5 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9396 Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808035Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#63854}
-
Clemens Hammacher authored
This allows to remove special casing for the {count == 0} case, which was needed because {memmove} does not accept {nullptr} arguments even if the {count} is zero. R=leszeks@chromium.org Bug: v8:9396 Change-Id: Iaef3cdbbffa74c2ba1c4e4501dafd943282cbcd9 Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807366Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63838}
-
- 13 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
After https://crrev.com/c/1800575 and https://crrev.com/c/1803343, which tried to fix this on occuring compile errors, this CL systematically adds the <memory> include to each header that uses {std::unique_ptr}. R=sigurds@chromium.org TBR=mlippautz@chromium.org,alph@chromium.org,rmcilroy@chromium.org,verwaest@chromium.org Bug: v8:9396 Change-Id: If7f9c3140842f9543135dddd7344c0f357999da0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803349Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63767}
-
- 21 Aug, 2019 1 commit
-
-
Simon Zünd authored
With the added parenthesis from a previous CL, clang-format does a decent job of formatting the nested ternary operator statement. R=leszeks@chromium.org Change-Id: If2f5db766b6234a44f771c167f9831adda5dbd43 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762301 Auto-Submit: Simon Zünd <szuend@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63308}
-
- 06 Aug, 2019 1 commit
-
-
Simon Zünd authored
This CL fixes an upcoming clang compiler warning (-Wparentheses). BuildAsciiCharFlags uses ternary operator '?' together with bitwise or '|'. Bitwise or '|' binds stronger than '?', so BuildAsciiCharsFlags is basically: return check1(c) ? E1 : (0 | check2(c)) ? E2 : (0 | check3(c)) ? E3 : 0; This CL fixes this. Change-Id: I794ef4aa19786e61b23d1f2b35eff486cf6d569a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738850Reviewed-by: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#63091}
-