- 12 Dec, 2017 1 commit
-
-
Junliang Yan authored
Port 52ff3ae4 Original Commit Message: - Implement RunMicrotasks in CSA to prevent a potentially large number of jumps between C++ and JS code while consuming te queue. Appears to provide a ~60% speedup in microtask-heavy code, which from limited testing appears to scale linearly. The code-stub microtask pump bails out to the old C++ microtask pump if it encounters a CallHandlerInfo microtask, and remains in C++ for the remainder of the queue (returning to the JS/stub implementation after the bailed out queue is exhausted). - Add a variation of JSEntryStub which enters the new RunMicrotasks code stub. - Add a new RunMicrotasks helper to Execution, which uses the RunMicrotasks entry stub. R=caitp@igalia.com, joransiu@ca.ibm.com, jbarboza@ca.ibm.com BUG= LOG=N Change-Id: Ifa15ca19312bb92758e82d19c3e3fc0a8b908d82 Reviewed-on: https://chromium-review.googlesource.com/820197Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#50018}
-
- 11 Dec, 2017 37 commits
-
-
Sergiy Byelozyorov authored
TBR=sergiyb@chromium.org Bug: chromium:747960 Change-Id: I3767d335907f2b953b633c4ae20c5c9b2dc5d65b Reviewed-on: https://chromium-review.googlesource.com/820910 Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#50017}
-
Junliang Yan authored
Port 663b55aa R=gdeepti@chromium.org, joransiu@ca.ibm.com, jbarboza@ca.ibm.com BUG= LOG=N Change-Id: Ia8cfa8c0927915c4afa07ceac85140231c415a9b Reviewed-on: https://chromium-review.googlesource.com/820196Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#50016}
-
Sergiy Byelozyorov authored
TBR=machenbach@google.com No-Try: true Bug: chromium:747960 Change-Id: I3ec105f0ddc2856c95b2314c4e2dd285e040b330 Reviewed-on: https://chromium-review.googlesource.com/820830 Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by:
-
Deepti Gandluri authored
This patch implements the following F32x4 Ops: F32x4Splat, F32x4ExtractLane, F32x4ReplaceLane F32x4RecipApprox, F32x4RecipSqrtApprox F32x4Add, F32x4Sub, F32x4Mul, F32x4Min, F32x4Max, F32x4Eq, F32x4Ne, F32x4Gt, F32x4Ge BUG=V8:6020 Change-Id: I8267734d336f4bae6fed008d7b1f5faa428574df Reviewed-on: https://chromium-review.googlesource.com/816734Reviewed-by:
Bill Budge <bbudge@chromium.org> Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#50014}
-
Deepti Gandluri authored
The haddps instruction is needed to implement wasm SIMD F32x4 horizontal add. BUG=V8:6020 Change-Id: Ifff78f6c697b46e621f0fd6b7bb1b0e7824a3088 Reviewed-on: https://chromium-review.googlesource.com/820098Reviewed-by:
-
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:
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:
-
- 10 Dec, 2017 2 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:
-
