- 05 Aug, 2019 12 commits
-
-
Clemens Hammacher authored
Instead of exposing a {kNext} constant to be used to construct the next bitfield, expose a templatized {Next} type alias. This ensures that the storage type is the same for all bitfields created this way. It's also shorter. Apart from the expected changes in the code base, the AST node classes are changed to expose a {NextBitField} templated type alias instead of a {kNextBitFieldIndex} constant. They thus follow the same pattern as {BitField} itself. R=jkummerow@chromium.org, mstarzinger@chromium.org, verwaest@chromium.org Bug: v8:9396 Change-Id: I70a1b0bd71cde694ec53444de0ca55e4cf0a3836 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728615Reviewed-by:Yang Guo <yangguo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63068}
-
Georg Neis authored
This reverts commit a82ffb17. Reason for revert: dependency for reverting 9499ec0d Original change's description: > [turbofan] Introduce Hints::SingleConstant helper > > Bug: v8:7790 > Change-Id: I499e74f45a3997d32e75c962f0c59ce5c6819c5f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730989 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63030} TBR=neis@chromium.org,mslekova@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7790 Change-Id: I7b264cf913935219adf11022231cb5002175500d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735314Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63067}
-
Michael Achenbach authored
This reverts commit 3fc96631. Reason for revert: _on_event clashes with a the same function in timeout proc. Original change's description: > [test] Print hanging tests on linux on test-runner termination > > This will print the list of processes still running before and after > joining workers during termination. This will help debugging hanging > tests during flake-bisect or with num-fuzzer, which both terminate > on total timeout and currently still sometimes hang without printing > processes. > > Bug: v8:8292 > Change-Id: I124b65fa35b8d7a6aa198fcf50f2c20df94dc51a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735312 > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63065} TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ic29013e92c77a9905e06ee13a2449e033285eb36 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8292 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735317Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#63066}
-
Michael Achenbach authored
This will print the list of processes still running before and after joining workers during termination. This will help debugging hanging tests during flake-bisect or with num-fuzzer, which both terminate on total timeout and currently still sometimes hang without printing processes. Bug: v8:8292 Change-Id: I124b65fa35b8d7a6aa198fcf50f2c20df94dc51a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735312Reviewed-by:
Tamer Tas <tmrts@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#63065}
-
Georg Neis authored
This reverts commit 6d313607. Reason for revert: dependency for reverting 9499ec0d Original change's description: > [turbofan] Introduce SerializationPolicy enum > > This improves overall readability by replacing bool arguments. > > Bug: v8:7790 > Change-Id: I02f8f43088497c9503f253788ee5e0015c7edc2d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730991 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63032} TBR=neis@chromium.org,mslekova@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7790 Change-Id: If6fc192bd8ad9c75fde2cc4aac69922217bfb8f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735313Reviewed-by:
-
Simon Zünd authored
This CL changes {CreateApiFunction} to take an explicit native context to set on the newly created JSFunction. The CL also adds a new variant of {ApiNatives::InstatiateFunction}, that takes a native context and passes it through to {CreateApiFunction}. This is a refactoring in preparation for a bugfix. AccessorPairs can be instantiated lazily. At the time of lazy instantiation, the current context does not necessarily match the creation context of the holder of an AccessorPair. Bug: chromium:986063, chromium:989909 Change-Id: Idea4b5052f2baff5c3d916f5ab8ed5017b60699b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735308 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Mu Tao authored
Building cctest has linking error when gn's args has "is_component_build = true". This CL make the visibility of "MemOperand" and "UseScratchRegisterScope" from "hidden" to "default" to solve this problem. Change-Id: I3ebfaa25d598b4f2d626861b947c93d111d95456 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731213 Auto-Submit: Mu Tao <pamilty@gmail.com> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63062}
-
Darius Mercadier authored
Change-Id: I2e0632756ac92b18d2d9a30b03b698b533b34862 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722564Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Darius Mercadier <dmercadier@google.com> Cr-Commit-Position: refs/heads/master@{#63061}
-
Ulan Degenbaev authored
Increasing the number of scavenging tasks in the previous CL https://chromium-review.googlesource.com/c/v8/v8/+/1697245 has helped with GC performance but increased memory usage. This CL ensures that there are at least two scavenging tasks if the new space size is larger than one MB. Bug: chromium:982663,chromium:985731 Change-Id: I6edff8b90beb2740a5b75a51cf25f48aa5442482 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733074Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63060}
-
Joshua Litt authored
Relands 64bit atomic wait with ubsan fix, previously reviewed at: https://chromium-review.googlesource.com/c/v8/v8/+/1728260 This reverts commit 2a383f4c. Bug: v8:8100, v8:9576 Change-Id: Ibeec86c8a796bfbef9884cdb836892e902030bf3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733389 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by:
-
Ujjwal Sharma authored
Fix the issue involving inconsistent whitespace in BUILD.gn which broke Node's GN scraper. Refs: https://github.com/nodejs/node-v8/issues/113 Bug: v8:9579 Change-Id: I5313cd652634b393fb3eab13f0f2bd483a3c6a97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1734946 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/afb3374..d57f70e TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ib9125d2ace76afc466b898e362dceb5aa9efbe86 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735187Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#63057}
-
- 04 Aug, 2019 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/b2d6a40..afb3374 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I25440be508ac8ae6605e2bfbb099c4a524a90436 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735186Reviewed-by:
-
- 03 Aug, 2019 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/base/trace_event/common: https://chromium.googlesource.com/chromium/src/base/trace_event/common/+log/d0793a0..5e4fce1 Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7e9c87e..b2d6a40 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ec6ed57..93ee550 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/59bb8cc..921f6a1 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/8215b08..cd2137f TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Id9283dede4d0e54a263c0dbc848f6e03f61d4792 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731381Reviewed-by:
-
- 02 Aug, 2019 21 commits
-
-
Ulan Degenbaev authored
When the --initial-heap-size flag is set V8's heap will grow to that value without full GCs. Additionally, full GCs will be skipped if the heap size drops below that value. This patch also adds a comment for the initial_heap_size_in_bytes parameter of ResourceConstraints:ConfigureDefaultsFromHeapSize Change-Id: I85fda14bc6422af7bf2193d530efbc9b0bd0553d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728622 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Also add a IsExtreme(double) overload. This wasn't causing issues because there was no codepath which exercised it (only approx operations did). Change-Id: If7583fb567137c428d16c0d2cdfc37e086f7f3fd Bug: v8:8460 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726675Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#63053}
-
Dan Elphick authored
4th attempt to reland this after this revert: https://chromium-review.googlesource.com/c/v8/v8/+/1680553 Required fixes for default values in arrow function parameters and for eval scopes: https://chromium-review.googlesource.com/c/v8/v8/+/1710671 https://chromium-review.googlesource.com/c/v8/v8/+/1733077 Original change's description: > Enable lazy source positions by default > > Also adds a compile time flag which allows the default to be configured > so node can disable it since it hangs the node cpu profiler tests. Bug: v8:8510 Change-Id: I20fd82f636527e405d73fd5941b1b4c2f134b666 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733078 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63052}
-
Leszek Swirski authored
For variable proxies in a function inside an eval scope that point to a dynamic variable in the eval scope, the current scope resolution will find this variable only when the function is eagerly compiled, as the eval scope only exists during top-level eval compilation. This causes a mismatch between lazy- and eager- compiled functions. With this patch, we skip these dynamic variables during lookup, so that the lookup for the variable proxy always finds a kDynamicLocal or kDynamicGlobal, both when compiled lazily and eagerly. This is a minor pessimisation of performance (as we know that the lookup has to be dynamic), but unblocks other improvements which require idempotent bytecode generation (such as lazy source positions). Note that the alternative, of simply not tracking dynamic variables on the eval scope at all, is not viable due to needing this information during conflict detection. Bug: v8:8510 Bug: v8:9511 Change-Id: Ifa72ec05e9a97b7be418912340081b9656765fd4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733077 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Reviewed-by:
-
Yu Yin authored
MIPS64 has a user space of 2^40 bytes on most processors, address space limits needs to be smaller. 256G is ok, but it will cause many wasm tests get a OOM error. This patch also skip some tests which need correct IEEE-745 2008 NaN bit patterns on mips. Change-Id: I52968df3934e8748b2c42a0abf19db1540441d2b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1712929Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Yu Yin <xwafish@gmail.com> Cr-Commit-Position: refs/heads/master@{#63050}
-
Michael Starzinger authored
This makes sure the "parameters" and "results" properties of the passed FunctionType object can be arbitrary iterable objects, not just plain JavaScript arrays. R=clemensh@chromium.org TEST=mjsunit/wasm/type-reflection BUG=v8:7742 Change-Id: Icba18c418e549deba9fff1855be4956813b1a953 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733071 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Simon Zünd authored
This CL adds regression tests for two bugs where the wrong native context is used when lazy accessors are instantiated. The first bug injects an object created in context 1, into another context 2. The object has an accessor pair installed via FunctionTemplate. In context 2, the property descriptor of this accessor is retrieved, causing the JSFunction to be instantiated with the current context (context 2) instead of the creation context of the object (context 1). The second bug is similar. When breakpoints are set, the whole heap is walked and all lazy accessor pairs are instantiated. This again uses the current context instead of using the context from which a AccessorPair originates. Bug: chromium:986063, chromium:989909 Change-Id: Iaaea6e81f1b9f6b55fc7583b260aa9aea035a8d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730999Reviewed-by:
-
Leszek Swirski authored
It's too slow and flakes on "V8 Linux - full debug" Change-Id: I2a83a7a2de6a3865d230edb847a658b1b8b23bec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733076 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Joshua Litt authored
This reverts commit 6a87a478. Reason for revert: breaks ubsan Original change's description: > [atomics] Wire up 64 bit atomic Wait in JS > > Bug: v8:8100 > Change-Id: Ia93319493352e81e727596582cbb23e6e7d604fd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728260 > Commit-Queue: Joshua Litt <joshualitt@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63040} TBR=jkummerow@chromium.org,joshualitt@chromium.org Change-Id: Iac014af8238d4eef8fc95128b4603b8118ed3dc4 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8100 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733387 Auto-Submit: Joshua Litt <joshualitt@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Mike Stanton authored
JSBoundFunctionRef::serialized() and JSFunctionRef::serialized() should tolerate being called when the heap broker is disabled, because these methods are now called in the JSCallReducer (in order to log whether information was missing at serialization time). Bug: v8:7790 Change-Id: Iac8e68178422bd9bb4ebe2acb412ff42ac87cf4a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733075Reviewed-by:
-
Santiago Aboy Solanes authored
Previously we were also taking into account the machine type Change-Id: Ic76aad578f00ef24cf17b349d94cdade8f9ee29d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733072Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#63044}
-
Santiago Aboy Solanes authored
This is a reland of f5611402 Original change's description: > [ptr-compr][arm64] Temporarily enable pointer compression on arm64 > > ... and make sure that the arm64 ptr-compr bots proceed testing V8 without > pointer compression in order to keep testing the other config. > > Commented out the 'extra' variant since it was crashing. Opened a bug > regarding that: https://bugs.chromium.org/p/v8/issues/detail?id=9568 > > Similar to x64's https://chromium-review.googlesource.com/c/v8/v8/+/1607654 > > Bug: v8:7703 > Change-Id: Ifd46b029bab34524f9f536dcdbd1574f2ddcbf37 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724216 > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63019} Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng Bug: v8:7703 Change-Id: I1a82b87bf6db4e6d100aeffc29dae60ba73d8119 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730998 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Trying to use double_registers for fetching single precision fp values creates four different implementations of this method depending on the architecture, hence separating them out into their respective folder. Change-Id: Ide61fe2e7a95bd8427b377959b262633d8c57e61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730663Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#63042}
-
Ulan Degenbaev authored
This is a reland of bc33f5ae Contributed by titzer@chromium.org Original change's description: > [arraybuffer] Rearchitect backing store ownership > > This CL completely rearchitects the ownership of array buffer backing stores, > consolidating ownership into a {BackingStore} C++ object that is tracked > throughout V8 using unique_ptr and shared_ptr where appropriate. > > Overall, lifetime management is simpler and more explicit. The numerous > ways that array buffers were initialized have been streamlined to one > Attach() method on JSArrayBuffer. The array buffer tracker in the > GC implementation now manages std::shared_ptr<BackingStore> pointers, > and the construction and destruction of the BackingStore object itself > handles the underlying page or embedder-allocated memory. > > The embedder API remains unchanged for now. We use the > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > keep the backing store alive properly, even in the case of aliases > from live heap objects. Thus the embedder has a lower chance of making > a mistake. Long-term, we should move the embedder to a model where they > manage backing stores using shared_ptr to an opaque backing store object. TBR=yangguo@chromium.org BUG=v8:9380,v8:9221,chromium:986318 Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Joshua Litt authored
Bug: v8:8100 Change-Id: Ia93319493352e81e727596582cbb23e6e7d604fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728260 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by:
-
Zhang, Shiyu authored
During date parsing, a FixedArray is allocated to store intermediate values, which is slow. This CL holds the values on stack instead to save time. This increases the score of JetStream2 Date-format-tofte-SP case by ~2% on WhiskeyLake Chromebook. Contributed by hao.a.xu@intel.com Change-Id: I0d7a20a3ad9c57e3a225fff03efc2e434b20fbbc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726744 Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> Reviewed-by:
-
Joey Gouly authored
Before this change, the tagged pointer that was loaded was not decompressed. This makes LoadTaggedPointerFromInstance match the x64 implementation. Bug: v8:9568 Change-Id: I8fd6d3e8dd13514ae3ef423d1c417f72e1396e4a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730993 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Ulan Degenbaev authored
Bug: chromium:648568 Change-Id: I09ef3911d1817b57d5984ca4121b2579093a1d93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722563Reviewed-by:
-
Georg Schmid authored
Previously when creating a new generic struct, one had to explicitly provide all type arguments, e.g., for the generic struct struct Box<T: type> { const value: T; } one would initialize a new box using const aSmi: Smi = ...; const box = Box<Smi> { value: aSmi }; With the additions in this CL the explicit type argument can be omitted. Type inference proceeds analogously to specialization of generic callables. Additionally, this CL slightly refactors class and struct initialization, and make type inference more permissive in the presence of unsupported type constructors (concretely, union types and function types). R=jgruber@chromium.org, tebbi@chromium.org Change-Id: I529be5831a85d317d8caa6cb3a0ce398ad578c86 Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728617 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by:Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63036}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/bc4a3ca..7e9c87e Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/471a922..ec6ed57 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/447b45d..59bb8cc TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I19360b89c4dddcfa9c5533c12fe0ba8037636b3a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731372Reviewed-by:
-
Ng Zhi An authored
Based on the updates to spec at https://github.com/WebAssembly/simd/pull/89 Change-Id: Ie60037e4de7a6953708a98c708afc9a820e6aa97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728347Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#63034}
-
- 01 Aug, 2019 5 commits
-
-
Rong Wang authored
The mode without write barriers works only if incremental marking is disabled and the single generation mode is enabled. Bug: v8:9533 Change-Id: Iecf83b0810f757c9b50e7fb338a2905af938f1d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716471 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Georg Neis authored
This improves overall readability by replacing bool arguments. Bug: v8:7790 Change-Id: I02f8f43088497c9503f253788ee5e0015c7edc2d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730991 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63032}
-
Maya Lekova authored
When the flag is on and some of the functions don't have bytecode, we should gracefully print "no bytecode" instead of crashing. Bug: chromium:983267 Change-Id: Id4e3385cd871a2dd5bead38c29a41b38319cc8d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731003Reviewed-by:
-
Georg Neis authored
Bug: v8:7790 Change-Id: I499e74f45a3997d32e75c962f0c59ce5c6819c5f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730989 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
On Linux, both APIs uses {madvise} (and {SetPermissions} additionally does an {mprotect}), on windows they use different APIs. It turns out that {SetPermissions} with {kNoAccess} uses {VirtualFree} with {MEM_DECOMMIT}, so the pages will only be "reserved" afterwards. {DiscardSystemPages} on the other hand uses the {DiscardVirtualMemory} which tells the OS that the content of that memory can be discarded, but the pages stay "committed". Thus {SetPermissions} with {kNoAccess} frees significantly more memory than using {DiscardSystemPages}. R=mstarzinger@chromium.org Bug: v8:8217 Change-Id: I3555462a9c692f15ecb3eca7834eb181617d9ef9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730992Reviewed-by:
-
