- 11 Dec, 2017 32 commits
-
-
Justin Ridgewell authored
This is a separation of the DFA Unicode Decoder from https://chromium-review.googlesource.com/c/v8/v8/+/789560 I attempted to make the DFA's table a bit more explicit in this CL. Still, the linter prevents me from letting me present the array as a "table" in source code. For a better representation, please refer to https://docs.google.com/spreadsheets/d/1L9STtkmWs-A7HdK5ZmZ-wPZ_VBjQ3-Jj_xN9c6_hLKA - - - - - Now for a big copy-paste from 789560: Essentially, reworks a standard FSM (imagine an array of structs) and flattens it out into a single-dimension array. Using Table 3-7 of the Unicode 10.0.0 standard (page 126 of http://www.unicode.org/versions/Unicode10.0.0/ch03.pdf), we can nicely map all bytes into one of 12 character classes: 00. 0x00-0x7F 01. 0x80-0x8F (split from general continuation because this range is not valid after a 0xF0 leading byte) 02. 0x90-0x9F (split from general continuation because this range is not valid after a 0xE0 nor a 0xF4 leading byte) 03. 0xA0-0xBF (the rest of the continuation range) 04. 0xC0-0xC1, 0xF5-0xFF (the joined range of invalid bytes, notice this includes 255 which we use as a known bad byte during hex-to-int decoding) 05. 0xC2-0xDF (leading bytes which require any continuation byte afterwards) 06. 0xE0 (leading byte which requires a 0xA0-0xBF afterwards then any continuation byte after that) 07. 0xE1-0xEC, 0xEE-0xEF (leading bytes which requires any continuation afterwards then any continuation byte after that) 08. 0xED (leading byte which requires a 0x80-0x9F afterwards then any continuation byte after that) 09. 0xF1-F3 (leading bytes which requires any continuation byte afterwards then any continuation byte then any continuation byte) 10. 0xF0 (leading bytes which requires a 0x90-0xBF afterwards then any continuation byte then any continuation byte) 11. 0xF4 (leading bytes which requires a 0x80-0x8F afterwards then any continuation byte then any continuation byte) Note that 0xF0 and 0xF1-0xF3 were swapped so that fewer bytes were needed to represent the transition state ("9, 10, 10, 10" vs. "10, 9, 9, 9"). Using these 12 classes as "transitions", we can map from one state to the next. Each state is defined as some multiple of 12, so that we're always starting at the 0th column of each row of the FSM. From each state, we add the transition and get a index of the new row the FSM is entering. If at any point we encounter a bad byte, the state + bad-byte-transition is guaranteed to map us into the first row of the FSM (which contains no valid exiting transitions). The key differences from Björn's original (or his self-modified) DFA is the "bad" state is now mapped to 0 (or the first row of the FSM) instead of 12 (the second row). This saves ~50 bytes when gzipping, and also speeds up determining if a string is properly encoded (see his sample code at http://bjoern.hoehrmann.de/utf-8/decoder/dfa/#performance). Finally, I've replace his ternary check with an array access, to make the algorithm branchless. This places a requirement on the caller to 0 out the code point between successful decodings, which it could always have done because it's already branching. R=marja@google.com Bug: Change-Id: I574f208a84dc5d06caba17127b0d41f7ce1a3395 Reviewed-on: https://chromium-review.googlesource.com/805357 Commit-Queue: Justin Ridgewell <jridgewell@google.com> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#50012}
-
Michal Majewski authored
Since we have only unittests that are under GoogleTestSuite there is no need to keep it as a default suite and we can make it specific for unittests. Bug: v8:6917 Change-Id: Ie2d57342773f228dea72184ab0f2abfc9d2daa70 Reviewed-on: https://chromium-review.googlesource.com/819253 Commit-Queue: Michał Majewski <majeski@google.com> Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#50011}
-
Daniel Ehrenberg authored
Includes drive-by fix of a small BigInt bug, as caught by test262/built-ins/BigInt/constructor-from-string-syntax-errors Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ic3b78310912f84bbf904a1fcb7ddf2d7eb2df013 Reviewed-on: https://chromium-review.googlesource.com/817775Reviewed-by:
Sathya Gunasekaran (ooo until 12/12) <gsathya@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#50010}
-
Mathias Bynens authored
The use counter was originally added in https://chromium.googlesource.com/v8/v8/+/d3c9812143f14fa616ebe2581f8b0a14f725d92e (https://chromium-review.googlesource.com/c/v8/v8/+/693155). The CL that removes the plumbing in Chromium is here: https://chromium-review.googlesource.com/c/chromium/src/+/819632 BUG=v8:6827 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ie5f861fe2a64454e682d8cd0618c948642a32886 Reviewed-on: https://chromium-review.googlesource.com/819553 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
-
Adam Klein authored
Bug: v8:7069 Change-Id: I878ea42207013a76de859c96f3cb5e2d93aa7927 Reviewed-on: https://chromium-review.googlesource.com/803908Reviewed-by:
-
Ulan Degenbaev authored
This adds two fields to the HeapStatistics struct: - number_of_native_contexts, - number_of_detached_contexts. Bug: chromium:793789 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: If6942a97fd22a9e70781eed2aa286aba4c0e7f70 Reviewed-on: https://chromium-review.googlesource.com/819730 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#50007}
-
Clemens Hammacher authored
Instead of holding four ZoneLists, which always have the same length anyway, just store all information in one struct, being held in one ZoneList. There is probably more optimization potential in the generation and encoding of safepoint tables; this is a first step to reduce its overhead. R=mstarzinger@chromium.org Bug: v8:7109 Change-Id: Ib4f752958c8d5713b46324e76003cd815e5ffd2d Reviewed-on: https://chromium-review.googlesource.com/817197 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#50006}
-
Ulan Degenbaev authored
This adds the following histograms: - V8.GCBackgroundMarking - V8.GCBackgroundScavenger - V8.GCBackgroundSweeping Bug: chromium:792552 Change-Id: Iae6fa3258f4fe0d4ed5e415c541a6d29101893a9 Reviewed-on: https://chromium-review.googlesource.com/819530Reviewed-by:
-
Ben L. Titzer authored
This CL introduces a small struct to hold the {mem_start} and {mem_size} node pointers that are managed in the function body decoder's SSA environment. This struct insulates the function body decoder from further changes in how context-specific information is represented in the compiler. R=clemensh@chromium.org CC=mstarzinger@chromium.org Bug: Change-Id: If17bef9fd2490ac11e4f3b3614f91333bb0b9528 Reviewed-on: https://chromium-review.googlesource.com/817282Reviewed-by:Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Ben L. Titzer <titzer@google.com> Cr-Commit-Position: refs/heads/master@{#50004}
-
Mircea Trofin authored
Straight forward bug - we took a naked pointer after which we perform an allocation. Bug: chromium:793671 Change-Id: I0cebd606c31edaca27abedc19bc878204eb9a18b Reviewed-on: https://chromium-review.googlesource.com/818634 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
-
Sigurd Schneider authored
TBR=neis@chromium.org Bug: v8:7127 Change-Id: Ic7c98f0f03d57fc748badddb921430818ec2f790 Reviewed-on: https://chromium-review.googlesource.com/819351 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50002}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: Ib7e625763f0e017fe4490fb87c4e90e8d57489fd Reviewed-on: https://chromium-review.googlesource.com/817442Reviewed-by:
-
Andreas Haas authored
This reverts commit 1e49864f. Reason for revert: Crashing test on the waterfall https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Linux_gcc_4.8%2F16871%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2FReturnMultipleRandom%2F0 Original change's description: > [turbofan] Implement on-stack returns (Intel) > > Add the ability to return (multiple) return values on the stack: > > - Extend stack frames with a new buffer region for return slots. > This region is located at the end of a caller's frame such that > its slots can be indexed as caller frame slots in a callee > (located beyond its parameters) and assigned return values. > - Adjust stack frame constructon and deconstruction accordingly. > - Extend linkage computation to support register plus stack returns. > - Reserve return slots in caller frame when respective calls occur. > - Introduce and generate architecture instructions ('peek') for > reading back results from return slots in the caller. > - Aggressive tests. > - Some minor clean-up. > > So far, only ia32 and x64 are implemented. > > Change-Id: I9532ad13aa307c1dec40548c5b84600fe2f762ce > Reviewed-on: https://chromium-review.googlesource.com/766371 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49994} TBR=titzer@chromium.org,rossberg@chromium.org,ahaas@chromium.org Change-Id: Ib257e92448942f8ef07d5ef246f9381f4784f014 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/819637Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#50000}
-
Georg Neis authored
R=jarin@chromium.org Bug: v8:6791 Change-Id: Ie030a79accebd7c43f19bcebefa7cd1951d67c2e Reviewed-on: https://chromium-review.googlesource.com/808937Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#49999}
-
Georg Neis authored
Also put an UNREACHABLE into an impossible case in NumberOpFromSpeculativeNumberOp. R=jarin@chromium.org Bug: Change-Id: I681b7bc58de5038497667cb48fdcd79a73abe1c2 Reviewed-on: https://chromium-review.googlesource.com/819415Reviewed-by:
-
Jeremy Roman authored
The parser holds a single vector whose backing storage is reused in calls to ParseJsonObject, so that once we reach the peak number of unstored properties no more allocations are required. This improves performance of parsing inputs like those in Speedometer VanillaJS by about 2% in my local measurement, and would presumably do better on more pathological inputs. This should also have the side effect of reducing peak memory usage at this time slightly, since we do fewer zone allocations which cannot be freed until the parse finishes. Reland switches to use std::vector::data instead of operator[] to avoid an index check in debug MSVC. In such cases the out-of-bounds pointer cannot be dereferenced, so it is legal. Bug: chromium:771227 Change-Id: I21837196372c904bfc799cd14353a73d11dcff32 Reviewed-on: https://chromium-review.googlesource.com/804062Reviewed-by:
-
Sigurd Schneider authored
Bug: v8:7127 Change-Id: I79be6acaa04623fe9a5d314de5cb10811724db5f Reviewed-on: https://chromium-review.googlesource.com/814401 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
We have to ensure that replacements do not have replacements because otherwise a changed replacement (of the replacement) wouldn't trigger graph revisitations. However, this invariant can be temporarily violated when the information propagated along the effect chain is outdated for another reason. So we should only check this for the final fixed-point. Bug: chromium:787959 Change-Id: I4a6b2c4f6ff3205649c0f866654900d4ab126acf Reviewed-on: https://chromium-review.googlesource.com/817777Reviewed-by:
-
Andreas Haas authored
Add the ability to return (multiple) return values on the stack: - Extend stack frames with a new buffer region for return slots. This region is located at the end of a caller's frame such that its slots can be indexed as caller frame slots in a callee (located beyond its parameters) and assigned return values. - Adjust stack frame constructon and deconstruction accordingly. - Extend linkage computation to support register plus stack returns. - Reserve return slots in caller frame when respective calls occur. - Introduce and generate architecture instructions ('peek') for reading back results from return slots in the caller. - Aggressive tests. - Some minor clean-up. So far, only ia32 and x64 are implemented. Change-Id: I9532ad13aa307c1dec40548c5b84600fe2f762ce Reviewed-on: https://chromium-review.googlesource.com/766371 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#49994}
-
sreten.kovacevic authored
Fixes problem with compilation in wasm-compiler.cc Bug: Change-Id: I2c38a4235b53467715d2199462d995b012e63bf9 Reviewed-on: https://chromium-review.googlesource.com/819270Reviewed-by:
-
Clemens Hammacher authored
Moving a register to itself is not only unnecessary overhead, it also breaks invariants in the StackTransferRecipe. R=ahaas@chromium.org Bug: v8:6600, chromium:793551 Change-Id: I659fd66b4f2d4564c437ed9fb048322af4299d97 Reviewed-on: https://chromium-review.googlesource.com/819231Reviewed-by:
-
Benedikt Meurer authored
Explain why we still have kNumber in addition to kNumberOrOddball, although the original motivation, which was Crankshaft, is gone now. Bug: v8:7109 Change-Id: I33016fbfa96bb0db57473b6d0c720fa1389d11f1 Reviewed-on: https://chromium-review.googlesource.com/817439Reviewed-by:
-
Benedikt Meurer authored
The CompareOperationFeedback documentation was outdated and there was an invalid TODO on it that suggested to unify this with the BinaryOperationFeedback which in retrospect doesn't make a lot of sense. Bug: v8:7109 Change-Id: Ibf748e242db55430f29d305f1ef1df6d44449481 Reviewed-on: https://chromium-review.googlesource.com/819090Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#49990}
-
Clemens Hammacher authored
This helps to debug issues with maintaining the cache state, and also understanding errors in the generated code. Unfortunately, it requires buffering the trace output in the decoder, since the interface is called in between, and the output would be messed up otherwise. R=titzer@chromium.org Bug: v8:6600 Change-Id: Ie8af8f7f619f3909ea52268241b883a4d4de79fa Reviewed-on: https://chromium-review.googlesource.com/813972 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Ulan Degenbaev authored
Bug: Change-Id: I49a259b8911969aace193cc3d0b18e4b8bcac7b8 Reviewed-on: https://chromium-review.googlesource.com/818344Reviewed-by:
-
peterwmwong authored
Support inlining Array.prototype.find in Turbofan. Quick benchmarks show >2x improvement for Smi and Double packed arrays: https://github.com/peterwmwong/v8-perf/blob/master/array-find-tf/README.md Bug: chromium:791045, v8:1956 Change-Id: I9a6882be9bc3e1e84df372a24bd0f85897cf92a0 Reviewed-on: https://chromium-review.googlesource.com/818193Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#49987}
-
Jaroslav Sevcik authored
For the JS object allocation case, we materialize children_count - 1 objects. However, we already materialized the map and property array, so this could materialize one object beyond the JS object. If there is no such object, we would go out-of-bounds. Bug: chromium:792330 Change-Id: I5ed5e4ddde9de9789bb2531a48a0d87c80bd156c Reviewed-on: https://chromium-review.googlesource.com/817315 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
This xor can never change the number of collisions, so it should be safe to remove. Bug: Change-Id: I253c0ece422f66e7cba15b13c041cfb6c8361674 Reviewed-on: https://chromium-review.googlesource.com/809113Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#49985}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: I251ea6e2c0e96b546e6fb96679ef4fc51e4adaa2 Reviewed-on: https://chromium-review.googlesource.com/817414Reviewed-by:
-
cjihrig authored
Change-Id: I12f67d79c11a209b02262c282a27cc7ef6afc14b Reviewed-on: https://chromium-review.googlesource.com/806774Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#49983}
-
Jaroslav Sevcik authored
This relands commit e71b8022. This can now back in as the fix for chromium:787301 had enough time to be tested in Canary. Original change's description: > [deoptimizer] Staged materialization of objects. > > The existing object materialization in the deoptimizer has the following problems: > > - Objects do not necessarily verify during materialization (because during the > depth first walk we might have inconsistent objects). > > - Stack can overflow (because we just materialize using recursive calls). > > - We generalize object fields. > > > This CL re-implements the materialization algorithm to solve this problem. The > new implementation creates the objects in two steps: > > 1. We allocate space for all the objects. In general, we allocate ByteArrays > of the right size. For leaf objects that cannot participate in cycles, > we build and initialize the materialized objects completely. > > For JS objects, we insert markers into the byte array at the positions > where unboxed doubles are expected. > > 2. We initialize all the objects with the proper field values and change the > map from the ByteArray map to the correct map. This requires some sync > with the concurrent marker (Heap::NotifyObjectLayoutChange). > > When initializing the JS object fields, we make sure that we respect > the unboxed double marker. > > Bug: chromium:770106, v8:3836 > Change-Id: I1ec466a9d19db9538df4ba915516d4c3ca825632 > Reviewed-on: https://chromium-review.googlesource.com/777559 > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49821} Bug: chromium:770106, v8:3836 Change-Id: Ied6c4e0fbae52713e55ae6dc13794a7521dbb8a5 Reviewed-on: https://chromium-review.googlesource.com/817745Reviewed-by:
-
jing.bao authored
Implement IA32Movdqu Add vmovdqu and Movdqu macro Bug: Change-Id: Idc2b5c99adf38d6120ff451bde40d4ad8f2046de Reviewed-on: https://chromium-review.googlesource.com/815944Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Jing Bao <jing.bao@intel.com> Cr-Commit-Position: refs/heads/master@{#49981}
-
- 10 Dec, 2017 3 commits
-
-
Mikhail Gusarov authored
If the source checkout had 'debug' somewhere in the path name, then IsDebuggerFile() marked all modules as debug ones, which triggered an assertion during snapshot generation. Bug: Change-Id: I93537efca9152c5469bb760f32ca53b06351f7a4 Reviewed-on: https://chromium-review.googlesource.com/809205Reviewed-by:
-
Bill Budge authored
- Remove unnecessary LSAN #include. - Use i:: instead of internal:: for consistency. Bug: Change-Id: I783b28402bf9c661e51b629167ec73b98a6b9fd7 Reviewed-on: https://chromium-review.googlesource.com/818198Reviewed-by:
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/d1735e8..ca599b0 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I76ab6088eecbfd6ae27c76ed0f39c51f6918f903 Reviewed-on: https://chromium-review.googlesource.com/817589Reviewed-by:
v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#49978}
-
- 09 Dec, 2017 3 commits
-
-
Caitlin Potter authored
await expressions are an invalid destructuring target, and should result in a SyntaxError when used in a position where a destructuring target is expected. BUG=v8:7173 R=marja@chromium.org, adamk@chromium.org Change-Id: I1bdb4bc13cb2e3e904fc4389a6e0abca1e0ed17f Reviewed-on: https://chromium-review.googlesource.com/811946Reviewed-by:
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/404c19d..d1735e8 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/16753e0..d624b3c Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/26f7d8a..e3b480d TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I2b61a541b5ff881d1d911f2b560661b8c1f0be7d Reviewed-on: https://chromium-review.googlesource.com/818157Reviewed-by:
-
https://crrev.com/c/802322Eric Holk authored
Bug: v8:7143 Change-Id: Ie8eee40ba1761a5790dc67a8ce03d2b2cb949722 Reviewed-on: https://chromium-review.googlesource.com/815677 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
-
- 08 Dec, 2017 2 commits
-
-
Ali Ijaz Sheikh authored
NewSpace::UpdateInlineAllocationLimit was computing the limit slighly differently. Make old space and new space more consistent. The way new space does it makes more sense as, logically, the step starts from beyond the current object being allocated (size_in_bytes). This behaviour change in preperation for a subsequent CL that refactors a common SpaceWithLinearArea::ComputeLimit. NewSpace: :UpdateInlineAllocationLimit and PagedSpace::ComputeLimit into Change-Id: Ibe918d46dccf8e80ed35c770b3c365c3970d07ea Reviewed-on: https://chromium-review.googlesource.com/815277Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com> Cr-Commit-Position: refs/heads/master@{#49974}
-
Bill Budge authored
- Changes d8 ArrayBuffer::Allocators to restrict size to < 2GB on the Allocate/AllocateUninitialized paths. Reserve can still create larger ArrayBuffers. Bug: chromium:793196 Change-Id: I662f8c681f715457d630df31039a1ea4d17cfafc Reviewed-on: https://chromium-review.googlesource.com/817763 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
-
