- 26 Nov, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Scopes in V8 are used to guarantee one or more properties during its lifetimes. If a scope is not named e.g MyClassScope(args) instead of MyClassScope scope(args) it will get created and automatically destroyed and therefore, being useless as a scope. This CL would produce a compiling warning when that happens to ward off this developer error. Follow-up to ccrev.com/2552415 in which it was introduced and implemented for Guard classes. Change-Id: Ifa0fb89cc3d9bdcdee0fd8150a2618af5ef45cbf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555001 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71425}
-
- 11 Nov, 2020 1 commit
-
-
Clemens Backes authored
Replace by explicitly deleting the copy constructor and copy assignment operator. R=zhin@chromium.org Bug: v8:11074 Change-Id: I30f4ff5ace47622cfb9891ee6a4d4f815ceb0ba3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2523314Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71115}
-
- 18 Jun, 2020 2 commits
-
-
Clemens Backes authored
Instead of creating temporary {std::vector}s (which always allocate on the heap) create more vectors on the stack, via initializer lists. As this is "only" a fuzzer, performance is not really critical, but still has some impact on the efficiency of the whole fuzzer. That said, this CL is mostly a cleanup to replace unwanted code pattern by better code. R=jkummerow@chromium.org Change-Id: I924c15e5d64ed584fc96c85715eef1dca5aef150 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249928 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#68413}
-
Jakob Gruber authored
Introduced in https://crrev.com/c/2250243. CONSTEXPR_DCHECK(cond) replaces the longer #if V8_HAS_CXX14_CONSTEXPR DCHECK(cond); #endif pattern. Change-Id: I636e5b4b40bffb29b2e82c81285b2ef78a822745 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250244Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68402}
-
- 09 Jun, 2020 1 commit
-
-
Clemens Backes authored
The existing {OwnedVector::New} value-initializes all elements, which means zeroing them in case on integral types. In many cases though we know that we will overwrite the content anyway, so the initialization is redundant. In the case of assembly buffers for wasm compilation, this zeroing showed up with several percent of execution times for some benchmarks. Hence this CL introduces a new {OwnedVector::NewForOverwrite} (along the lines of {std::make_unique_for_overwrite}), which only default-initializes the values (meaning no initialization for integral values). R=thibaudm@chromium.org Bug: v8:10576 Change-Id: I8d2806088acebe8a264dea2c7ed74b0423671d4f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2237140 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#68268}
-
- 17 Apr, 2020 2 commits
-
-
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}
-
Clemens Backes authored
Test some constexpr factories. StaticCharVector is not actually constexpr, this will be fixed in a follow-up CL. R=leszeks@chromium.org Bug: v8:10426 Change-Id: I16fdf79cd7d4b3f54d7cf73e15bdff2306810f06 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154192 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67210}
-
- 05 Mar, 2020 3 commits
-
-
Clemens Backes authored
This is a reland of 79398ab0 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
-
Clemens Backes authored
This reverts commit 79398ab0. Reason for revert: Makes UBSan unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10186 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} TBR=jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,tebbi@chromium.org Change-Id: Id80aa82cfce8942879031032b322ee66855b5600 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10254 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089933Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66597}
-
Clemens Backes authored
Also, save dynamic allocations (plus their memory overhead). This is realized by storing the relocation information, source position table, and protected instruction information together in one "metadata" byte array. For each of the three components, we just store their size, such that the accessors can return the respecitive {Vector} views as before. This makes each WasmCode object 24 bytes smaller on 64-bit architectures. It also saves a few more bytes per code object because less padding is needed for the individual allocations, and each dynamic allocation comes with some constant memory overhead. Since the protected instructions will just be stored in a byte array now, some APIs are refactored to just return that byte array directly (instead of an array of {ProtectedInstructionData}). This also simplifies serialization and deserialization, and will allow for switching to a more compact representation in the future. Drive-by: Add some more checks to {Vector::cast} to protect against undefined behaviour. R=ahaas@chromium.org Bug: v8:10254 Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66596}
-
- 20 Feb, 2020 1 commit
-
-
Clemens Backes authored
If multiple code spaces are created, each of them currently gets its own jump table (on 64 bit platforms). Since we try to allocate new code spaces right after existing ones, this is often not necessary. We could instead reuse the existing jump table(s). This saves code space for the unneeded jump tables and avoid the cost of patching the redundant jump tables when we replace code objects. This CL implements this by checking whether an existing jump table (or pair of far jump table and (near) jump table) fully covers a new code space, and reuses the existing jump table in that case. R=ahaas@chromium.org Change-Id: Id8751b9c4036cf8f85f9baa2b0be8b2cfb5716ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043846Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66364}
-
- 20 Jan, 2020 1 commit
-
-
Clemens Backes authored
I hit this issue in an unrelated CL and it took me a while to figure out what's happening. This CL will allow the creation of constant OwnedVectors via {OwnedVector<const T>::Of(collection)}. R=tebbi@chromium.org Change-Id: I337077a6c3960a2a2a8d857bec7450f664b87a3b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010109Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65868}
-
- 26 Nov, 2019 1 commit
-
-
Clemens Backes authored
R=jkummerow@chromium.org Bug: v8:9810 Change-Id: I1ce34f5c34c0a858cb725d56ef47d9dbd697a1e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934336 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65182}
-
- 25 Nov, 2019 1 commit
-
-
Clemens Backes authored
Also, fix the implementation of {operator==} and add {operator!=}. {operator==} could not be instantiated on a {Vector<T>} where T is not const, as it would access the fields of another instantiation of Vector ({T} vs {const T}). R=jkummerow@chromium.org Bug: v8:9810 Change-Id: I65c2d3071a781f6fe7a624b727d2770b43b7f7a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932363 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65155}
-
- 16 Oct, 2019 1 commit
-
-
Clemens Backes authored
DCHECKs are not really special, they just create a non-constexpr path within an otherwise constexpr function. Since C++14, this is allowed. Unfortunately, gcc only supports this since version 6, but we still need to support gcc 5. R=ulan@chromium.org Change-Id: If74486144abafa5bbdcdbb9a567ee9295ac4cfc7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862568Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64310}
-
- 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}
-
- 12 Jul, 2019 1 commit
-
-
Jakob Kummerow authored
Change-Id: I51c25c3e41d11ac2419aac1041fe92192f8fdb9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698382 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62688}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 23 May, 2019 1 commit
-
-
Yang Guo authored
NOPRESUBMIT=true TBR=mstarzinger@chromium.org Bug: v8:9247 Change-Id: I4cd6b79a1c2cba944f6f23caed59d4f1a4ee358b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624217 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61790}
-
- 03 May, 2019 1 commit
-
-
Clemens Hammacher authored
This is a reland of b6fb2707. Unchanged reland, TSan issue were fixed in https://crrev.com/c/1593340 and https://crrev.com/c/1594553. Original change's description: > [wasm][gc] Free WasmCode objects > > This adds the next step to freeing code: We free the actual C++ > {WasmCode} objects. This will cause UAF if any C++ code uses stale > references. > The underlying machine code will still not be freed. > > For simplicity, this CL changes the vector of owned_code to an ordered > set, such that lookup and removal is much simpler. The drawback is that > insertion is now more expensive. > > R=mstarzinger@chromium.org > > Bug: v8:8217 > Change-Id: I07fc81167816637fbaad6c06ff79e3f952f2fde8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593080 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61165} TBR=mstarzinger@chromium.org Bug: v8:8217 Change-Id: I809832bb609663d794c7aafcf071823db7fb6212 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594436 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61215}
-
- 02 May, 2019 2 commits
-
-
Clemens Hammacher authored
This reverts commit b6fb2707. Reason for revert: TSan issues, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/26177 Original change's description: > [wasm][gc] Free WasmCode objects > > This adds the next step to freeing code: We free the actual C++ > {WasmCode} objects. This will cause UAF if any C++ code uses stale > references. > The underlying machine code will still not be freed. > > For simplicity, this CL changes the vector of owned_code to an ordered > set, such that lookup and removal is much simpler. The drawback is that > insertion is now more expensive. > > R=mstarzinger@chromium.org > > Bug: v8:8217 > Change-Id: I07fc81167816637fbaad6c06ff79e3f952f2fde8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593080 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61165} TBR=mstarzinger@chromium.org,clemensh@chromium.org Change-Id: I167a8d806a8c6ac1c90e0743cdf86d492389bbed No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8217, v8:9200 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593305Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61176}
-
Clemens Hammacher authored
This adds the next step to freeing code: We free the actual C++ {WasmCode} objects. This will cause UAF if any C++ code uses stale references. The underlying machine code will still not be freed. For simplicity, this CL changes the vector of owned_code to an ordered set, such that lookup and removal is much simpler. The drawback is that insertion is now more expensive. R=mstarzinger@chromium.org Bug: v8:8217 Change-Id: I07fc81167816637fbaad6c06ff79e3f952f2fde8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593080 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61165}
-
- 30 Apr, 2019 1 commit
-
-
Clemens Hammacher authored
Instead, use std::sort and std::stable_sort at the 3 (!) call sites directly. This also removes the weird comparer adaptors from Vector, which are only used in ZoneList. R=jkummerow@chromium.org Bug: v8:9183 Change-Id: I4d0377976fb0a965cb68a21d4307df9ba09fd55d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587394Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61109}
-
- 29 Apr, 2019 2 commits
-
-
Clemens Hammacher authored
The {Vector} class does not use it any more. External uses should be converted to {size_t} instead of {int}. This CL removes the function from vector.h and updates all users to either use {size_t}, or cast to {int} explicitly. In tests, no further checks are needed if the string is a constant. R=mstarzinger@chromium.org Bug: v8:9183 Change-Id: I60f99302504c74d8a7c79b147ca01d8ba61b6879 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587393Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61092}
-
Clemens Hammacher authored
Our {Vector} template provides both {start} and {begin} methods. They return exactly the same value. Since the {begin} method is needed for iteration, and is also what standard containers provide, this CL switches all uses of the {start} method to use {begin} instead. Patchset 1 was auto-generated by using this clang AST matcher: callExpr( callee( cxxMethodDecl( hasName("start"), ofClass(hasName("v8::internal::Vector"))) ), argumentCountIs(0)) Patchset 2 was created by running clang-format. Patchset 3 then removes the now unused {Vector::start} method. R=jkummerow@chromium.org TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org Bug: v8:9183 Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61081}
-
- 24 Apr, 2019 1 commit
-
-
Clemens Hammacher authored
Use the existing {ArrayVector} method for this, which reads nicer. In some places, I replaced a stack-allocated array by {EmbeddedVector} to avoid the {ArrayVector} call. R=mstarzinger@chromium.org Bug: v8:8834 Change-Id: I5560c07f2775338fefd11acf67a540e003428e74 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578899Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60975}
-
- 23 Apr, 2019 3 commits
-
-
Clemens Hammacher authored
The {Vector} class stores the size in a {size_t} since a while, but many accessors and constructors still accept an {int}. This CL removes all {int} uses except for the explicit {length()} accessor. It also adds a comment to avoid this accessor if possible. The {StrLength} function still has several users outside of vector.h, which I plan to remove in a follow-up CL. R=mstarzinger@chromium.org Bug: v8:8834 Change-Id: I33c5b0e8b8b2cb3531716c1d99e4516a13d6ba1f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578480Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60950}
-
Clemens Hammacher authored
This CL fixes some issues with GC. 1) It removes dead code from the set of potentially dead code to avoid considering the same code for GC again and again. 2) It resets the {new_potentially_dead_code_size_} counter to avoid triggering too many GCs. 3) When code becomes dead after GC, do not unconditionally free it; just decrement its ref count (there might still be {WasmCodeRefScope}s holding the code alive). 4) Update the comment of the ref count to be more accurate. R=titzer@chromium.org Bug: v8:8217 Change-Id: I28e5a1fed74411b8473bb66ddbad3ffe7643f266 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1574518 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60949}
-
Clemens Hammacher authored
EmbeddedVector lives on the stack only, and should not be implicitly copied or assigned. This also removes remaining uses of the removed Vector::set_start method. R=sigurds@chromium.org Bug: v8:9142 Change-Id: I829e6ffad6b1a30baa6c874265e92d615dd0c981 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578458Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60940}
-
- 03 Apr, 2019 1 commit
-
-
Clemens Hammacher authored
All standard containers provide a method named {empty} to check whether the container is empty. On {base::Vector}, that method is named {is_empty}, while {empty} is an unused factory method for creating an empty {Vector}. This CL renames {is_empty} to {empty} and removes the unused factory method. R=leszeks@chromium.org Bug: v8:8834 Change-Id: I686bd07527801fbe783c412bc241221d8ec3660a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547862 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#60584}
-
- 26 Feb, 2019 1 commit
-
-
Sigurd Schneider authored
Remove EmbeddedVector from utils.h Bug: v8:8834, v8:8912 Change-Id: I04e9f12121757bd0b87c68d7a4a5b213c2d8b686 Reviewed-on: https://chromium-review.googlesource.com/c/1486473Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59854}
-
- 21 Jan, 2019 1 commit
-
-
Clemens Hammacher authored
This is a reland of 4e1d7c87. Failure on arm and arm64 is fixed by https://crrev.com/c/1411885. Original change's description: > [wasm] Split compilation in three stages > > In order to refactor ownership between objects in wasm compilation, the > compilation (executed by background tasks) is split in three stages: > getting a compilation unit (while holding a mutex), executing the work > (without any mutex and without keeping the NativeModule alive), and > submitting the work (with a mutex again). > > This CL prepares this design by splitting compilation from submission. > Both steps are still executed right after each other. This will be > changed in a follow-up CL. > > R=titzer@chromium.org > CC=mstarzinger@chromium.org > > Bug: v8:8689 > Change-Id: I2f92aee8e2f2d45470d8c63314ed026341630902 > Reviewed-on: https://chromium-review.googlesource.com/c/1414920 > Reviewed-by: Ben Titzer <titzer@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58929} TBR=titzer@chromium.org Bug: v8:8689 Change-Id: I58ff07d0e0ac8df0f6ee23c416f992954f4673d2 Reviewed-on: https://chromium-review.googlesource.com/c/1422748Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58959}
-
- 18 Jan, 2019 2 commits
-
-
Michael Achenbach authored
This reverts commit 4e1d7c87. Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/14986 Original change's description: > [wasm] Split compilation in three stages > > In order to refactor ownership between objects in wasm compilation, the > compilation (executed by background tasks) is split in three stages: > getting a compilation unit (while holding a mutex), executing the work > (without any mutex and without keeping the NativeModule alive), and > submitting the work (with a mutex again). > > This CL prepares this design by splitting compilation from submission. > Both steps are still executed right after each other. This will be > changed in a follow-up CL. > > R=titzer@chromium.org > CC=mstarzinger@chromium.org > > Bug: v8:8689 > Change-Id: I2f92aee8e2f2d45470d8c63314ed026341630902 > Reviewed-on: https://chromium-review.googlesource.com/c/1414920 > Reviewed-by: Ben Titzer <titzer@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58929} TBR=titzer@chromium.org,clemensh@chromium.org Change-Id: Ic3d0287b354ef5f834b76bc2cdc096d2231f4477 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8689 Reviewed-on: https://chromium-review.googlesource.com/c/1422917Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#58932}
-
Clemens Hammacher authored
In order to refactor ownership between objects in wasm compilation, the compilation (executed by background tasks) is split in three stages: getting a compilation unit (while holding a mutex), executing the work (without any mutex and without keeping the NativeModule alive), and submitting the work (with a mutex again). This CL prepares this design by splitting compilation from submission. Both steps are still executed right after each other. This will be changed in a follow-up CL. R=titzer@chromium.org CC=mstarzinger@chromium.org Bug: v8:8689 Change-Id: I2f92aee8e2f2d45470d8c63314ed026341630902 Reviewed-on: https://chromium-review.googlesource.com/c/1414920Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58929}
-
- 03 Jan, 2019 1 commit
-
-
Clemens Hammacher authored
Templates are nicer than macros, and in this case it's not more complex. R=tebbi@chromium.org Bug: v8:8562 Change-Id: I3aea7b4138f144166418c0827dd7c58ea459c670 Reviewed-on: https://chromium-review.googlesource.com/c/1392200Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58518}
-
- 02 Jan, 2019 1 commit
-
-
Clemens Hammacher authored
And use it in several places in wasm. R=tebbi@chromium.org Bug: v8:8562 Change-Id: I1e857baf33e99849eb32ac2c94e39d7f27b180c8 Reviewed-on: https://chromium-review.googlesource.com/c/1391757 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58495}
-
- 15 Nov, 2018 1 commit
-
-
Clemens Hammacher authored
We often need to create a {Vector} view of data owned by a container like {std::vector}. The canonical way to do this is this: Vector<T>{vec.data(), vec.size()} This pattern is repeating information which can be deduced automatically, like the type T. This CL introduces a {VectorOf} helper which can construct a {Vector} for any container providing a {data()} and {size()} accessor, and uses it to replace the pattern above. R=ishell@chromium.org Bug: v8:8238 Change-Id: Ib3a11662acc82cb83f2b4afd07ba88e579d71dba Reviewed-on: https://chromium-review.googlesource.com/c/1337584Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57538}
-
- 12 Nov, 2018 1 commit
-
-
Clemens Hammacher authored
After the first decoder error, the streaming processor should not be called again. To enforce this, reset the {processor_} field. This also makes the {ok_} field redundant. Note that this refactoring is also necessary for a future CL which makes the {StreamingProcessor} keep the {AsyncCompileJob} alive. By resetting the processor, we also remove that link. R=ahaas@chromium.org Bug: v8:7921 Change-Id: I42f5ed26a8f26c3dc8db5676557a0d82021e132e Reviewed-on: https://chromium-review.googlesource.com/c/1329179 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#57435}
-
- 12 Jul, 2018 1 commit
-
-
Clemens Hammacher authored
Instead of passing {uint8_t*, size_t} pairs as arguments, pass {Vector<uint8_t>}. This is less error prone and {Vector} provides some helpful methods. R=ahaas@chromium.org Bug: v8:7754 Change-Id: I7469054774618e0bd5c9d38501759b1b2c51d104 Reviewed-on: https://chromium-review.googlesource.com/1134773Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54406}
-
- 27 Jun, 2018 1 commit
-
-
Clemens Hammacher authored
Replace two more pairs of {std::unique_ptr} and {size_t} by {OwnedVector}. R=mstarzinger@chromium.org Change-Id: Ifdf03abf9759fbbb4adde76a494073625723a03d Reviewed-on: https://chromium-review.googlesource.com/1116785 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54057}
-