- 02 Aug, 2019 5 commits
-
-
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:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63038}
-
Ulan Degenbaev authored
Bug: chromium:648568 Change-Id: I09ef3911d1817b57d5984ca4121b2579093a1d93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722563Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63037}
-
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:
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@{#63035}
-
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 17 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 <neis@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63033}
-
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:Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63029}
-
Georg Neis authored
This CL adds new ProcessedFeedback subclasses, corresponding to various IC types: * ForIn * Comparison ops * Binary/Unary ops * InstanceOf * Calls The feedback is gathered at serialization time and used in several places, namely: * Bytecode graph building, * and its helper class JSTypeHintLowering (with its "early lowering") * Native context specialization * JSCallReducer Design doc: https://docs.google.com/document/d/1JLG0VFV8xmsAIJexU19xzlbNyP51ONqfo_Gf_2DcPC8/edit?usp=sharing Bug: v8:7790 Change-Id: I53c3d7a17f844384f38c4ee0f0b082c114217a02 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710663 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Georg Neis authored
From JSNativeContextSpecialization::ReduceKeyedLoadFromHeapConstant to JSNativeContextSpecialization::ReduceElementLoadFromHeapConstant. Change-Id: Ib07a6a4bd599dc71a9a100b2f1f6baef68acbe0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728618Reviewed-by:
-
Joshua Litt authored
now that we are shipping this by default, we can remove the flag. Change-Id: I298691df3eec934a5add1aa2a2748a0f3a884ab6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726452 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#63026}
-
Clemens Hammacher authored
The unittest for {WasmCodeManager} currently disables implicit allocations for win64 unwind info, but still deals with the implicitly allocated jump table. With the addition of a far jump table, this logic would get even more complex. Thus this CL introduces a testing flag on the {WasmCodeManager} to disable all implicit allocations, and uses that instead in the {WasmCodeManagerTest}. R=mstarzinger@chromium.org Bug: v8:9477 Change-Id: I45e4bc6b9fec6d7286bf6b45f778681ae0dba746 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725622 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: -
Maya Lekova authored
Now PropertyAccessBuilder::TryBuildLoadConstantDataField is heap-access free. Bug: v8:7790 Change-Id: Ibcc644270325d25da01af7f66e8a26fb57614718 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725614 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Leszek Swirski authored
This reverts commit 159df248. Reason for revert: Breaks large-classes-properties test (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906338563361079200/+/steps/Bisect_159df248/0/steps/Retry_-_isolates/0/logs/large-classes-properties/0) Original change's description: > [ic] Don't transition to premonomorphic state > > We used to use premonomorphic state to delay initializing the ICs. > This optimization was to avoid the cost of setting up handlers if the > code executed only once. With lazy feedback allocation we no longer > need this. > > This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and > StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to > runtime in the uninitialized state and use the builtin when there > is no feedback. > > > Change-Id: I1633e61ea74664da51348e362c34c47a017a264a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63020} TBR=mythria@chromium.org,verwaest@chromium.org Change-Id: I4fad4e8b881d4a3f8d12149e1797b217a317eaee No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730995Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63023}
-
Leszek Swirski authored
This reverts commit f5611402. Reason for revert: arm64 sim MSAN failures (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/28059) 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} TBR=machenbach@chromium.org,tmrts@chromium.org,solanes@chromium.org Change-Id: I7d96c8aa83fcabff7e9a82e0556811398fedc34c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7703 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730994Reviewed-by:
-
Michael Starzinger authored
This removes the explicit {kCallWithCallerSavedRegisters} opcode which is just a regular call node with special handling for saving/restoring caller saved registers before/after the call. This is now handled via the {CallDescriptor::kCallerSavedRegisters} flag. R=neis@chromium.org BUG=v8:9396 Change-Id: Ie6421085eb2be8a067040222cd5215a9b1013048 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728611Reviewed-by: -
Mythri A authored
We used to use premonomorphic state to delay initializing the ICs. This optimization was to avoid the cost of setting up handlers if the code executed only once. With lazy feedback allocation we no longer need this. This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to runtime in the uninitialized state and use the builtin when there is no feedback. Change-Id: I1633e61ea74664da51348e362c34c47a017a264a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63020}
-
Santiago Aboy Solanes authored
... 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/+/1724216Reviewed-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}
-
Maya Lekova authored
Bug: v8:7790 Change-Id: Icd0194924d7b0aa58f5b7ee74028cec9f5c39564 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715460Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/496479d..bc4a3ca Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2568b37..471a922 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/c075833..447b45d TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I5e3e3bf84ca86a7b7c702555f8a4206b0b08f5a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1729355Reviewed-by:
-
- 31 Jul, 2019 18 commits
-
-
Ng Zhi An authored
Bug: v8:8425 Change-Id: I4c883726daee1ab244e4bc2ce202cacf9bd3d50c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726400 Auto-Submit: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Ng Zhi An authored
The mask should cover the sign (1 bit), exponent (11 bits) and quiet bit (1 bit) of significand, total of 13 bits. The old mask only covered 9 bits. Change-Id: I6ec402b4cec34978eac8fa3e5452ad22540a93ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726984Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#63015}
-
Z Nguyen-Huu authored
Instead of having fast path for proxy only in Reflect.deleteProperty, it is also in delete operator. Bug: v8:6664 Change-Id: I3db919953e31f51a5dc4a504062bd691a6e17446 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717660 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
-
Dan Elphick authored
Wrapped functions don't recompile properly with lazy source positions so just force them to always collect the source positions. Fixes cctest/test-compiler/CompileFunctionInContext in the presence of --enable-lazy-source-positions and --stress-lazy-source-positions. Bug: v8:8510 Change-Id: I2402a441d4930be11dc037c6041cb577a63a3529 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709427 Commit-Queue: Dan Elphick <delphick@chromium.org> Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63013}
-
Deepti Gandluri authored
Bug: v8:9536 Change-Id: Ie9c47493ab29f604d6e43ef318e08618ee527fc3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728329Reviewed-by:
-
Francis McCabe authored
This reverts commit df8e6177. Reason for revert: Multiple flakes in apparently related areas: https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906409837768155568/+/steps/Check__flakes_/0/logs/BackingStoreTest.RacyGrowWasmMem.../0 Original change's description: > "Reland x3 [arraybuffer] Rearchitect backing store ownership" > > This is a reland of bc33f5ae > > 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. > > R=mlippautz@chromium.org > BUG=v8:9380,v8:9221,chromium:986318 > TBR=ulan@chromium.org > > Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191 > Reviewed-by: Ben Titzer <titzer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63007} TBR=mstarzinger@chromium.org,titzer@chromium.org,mlippautz@chromium.org Change-Id: If0266e5893b1325a332d5986337fa7ece2cb6943 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9380, v8:9221, chromium:986318 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1729549Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#63011}
-
Clemens Hammacher authored
R=ulan@chromium.org Bug: v8:9380 No-Try: true Change-Id: I319bbc607a738d78cb797691bcfcb9484f416324 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728619 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Seth Brenith authored
This is a reland of 4b15b984 Updates since original: fix an arithmetic overflow bug, remove an invalid DCHECK, add a unit test that would trigger that DCHECK. Original change's description: > [regexp] Better quick checks on loop entry nodes > > Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this > change is inspired by attempting to exit earlier from generated RegExp > code, when no further matches are possible because any match would be > too long. The motivating example this time is the following expression, > which tests whether a string of Unicode playing cards has five of the > same suit in a row: > > /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u > > A human reading this expression can readily see that any match requires > at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for > each repeated option reports its minimum distance to the end of a match > as zero. This is correct, because the LoopChoiceNode's behavior depends > on additional state (the loop counter). However, the preceding node, a > SET_REGISTER action that initializes the loop counter, could confidently > state that it consumes at least 10 characters. Furthermore, when we try > to emit a quick check for that action, we could follow only paths from > the LoopChoiceNode that are possible based on the minimum iteration > count. This change implements both of those "could"s. > > I expect this improvement to apply pretty broadly to expressions that > use minimum repetition counts and that don't meet the criteria for > unrolling. In this particular case, I get about 12% improvement on the > overall UniPoker test, due to reducing the execution time of this > expression by 85% and the execution time of another similar expression > that checks for n-of-a-kind by 20%. > > Bug: v8:9305 > > Change-Id: I319e381743967bdf83324be75bae943fbb5dd496 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62963} Bug: v8:9305 Change-Id: I992070d383009013881bf778242254c27134b650 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726674Reviewed-by:
-
Seth Brenith authored
This is a reland of 517ab73f Updates since original: now compressed pointers passed to the function GetObjectProperties are required to be sign-extended. Previously, the function allowed zero-extended values, but that led to ambiguity on pointers like 0x88044919: is it compressed or is the heap range actually centered on 0x100000000? Original change's description: > Add postmortem debugging helper library > > This change begins to implement the functionality described in > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit# > for investigating V8 state in crash dumps. > > This change adds a new library, v8_debug_helper, for providing platform- > agnostic assistance with postmortem debugging. This library can be used > by extensions built for debuggers such as WinDbg or lldb. Its public API > is described by debug-helper.h; currently the only method it exposes is > GetObjectProperties, but we'd like to add more functionality over time. > The API surface is restricted to plain C-style structs and pointers, so > that it's easy to link from a debugger extension built with a different > toolchain. > > This change also adds a new cctest file to exercise some basic > interaction with the new library. > > The API function GetObjectProperties takes an object pointer (which > could be compressed, or weak, or a SMI), and returns a string > description of the object and a list of properties the object contains. > For now, the list of properties is entirely based on Torque object > definitions, but we expect to add custom properties in future updates so > that it can be easier to make sense of complex data structures such as > dictionaries. > > GetObjectProperties does several things that are intended to generate > somewhat useful results even in cases where memory may be corrupt or > unavailable: > - The caller may optionally provide a type string which will be used if > the memory for the object's Map is inaccessible. > - All object pointers are compared against the list of known objects > generated by mkgrokdump. The caller may optionally provide the > pointers for the first pages of various heap spaces, to avoid spurious > matches. If those pointers are not provided, then any matches are > prefixed with "maybe" in the resulting description string, such as > "maybe UndefinedValue (0x4288000341 <Oddball>)". > > Bug: v8:9376 > > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62882} Bug: v8:9376 Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63008}
-
Ben L. Titzer authored
This is a reland of bc33f5ae 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. R=mlippautz@chromium.org BUG=v8:9380,v8:9221,chromium:986318 TBR=ulan@chromium.org Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port 556e4859 Original Commit Message: Instead of storing the values of the single precision floating point registers, get their values from the aliased double precision registers. This saves, on arm64, 184 bytes per deoptimisation kind function (552 in total) and 128 bytes in the RegisterValues class. R=joey.gouly@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: If38a721cfaefb7980902f4f963119cb88061e342 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726857Reviewed-by:
-
Georg Schmid authored
With the arrival of generic structs (https://chromium-review.googlesource.com/c/v8/v8/+/1714868) the existing type inference procedure for generic calls became incomplete, since it could not infer types that were only constrained as part of generic types. For instance, given struct Box<T: Type> { ... } macro unbox<T: type>(box: Box<T>): T the type argument (Smi) at the following call site const box: Box<Smi> = ...; unbox(box); could not be inferred. This CL re-implements the inference procedure and documents the semantics of type argument inference in Torque a bit more clearly. R=tebbi@chromium.org Change-Id: I868f16afbd9864b9c810ac49bc1639b467df939c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720812 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by:
-
Dan Elphick authored
Removes static modifier from global inline functions defined in globals.h. R=rmcilroy@chromium.org Bug: v8:9396 Change-Id: Ieacbcbf592d219fb50ab2d23dfbaba27246fb7ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728610Reviewed-by:
-
Michael Achenbach authored
Change-Id: Ica3d8ca233278e50e390aad37138942d23b5b8b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728612Reviewed-by:
-
Tom Tan authored
On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend doesn't emit unwinding info and also because it doesn't emit ABI compliant stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and documented below: https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0 This problem can be fixed similarly for Windows ARM64 by observing that V8 frames usually all have the same prolog which maintains a chain via frame pointer (fp or x29 register). stp fp, lr, [sp, ...] One exception is JSEntry which stops fp pointer chain and needs to be handled specially. So it is possible to define XDATA with UNWIND_CODE which specify how Windows should walk through V8 dynamic frames. The same as X64, since V8 Code objects are all allocated in the same code-range for an Isolate, it is possible to register at most 2 XDATA and a group of PDATA entries to cover stack walking for all the code generated inside that code-range. This is more than 1 PDATA/XDATA because according to the Windows ARM64 exeption handling document, 1 PDATA can cover less than 1MB code range (see below doc). https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling This PR implements stackwalk for Windows ARM64 to be on par with X64, including embedded builtins, jitted code and wasm jitted code, but not including register handler for handling exception only, because there is no backward compatibility to maintain for Windows ARM64 which was released since 1709 windows build. Bug: chromium:893460 Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/test/wasm-js/data: https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+log/b0c936c..a221f25 [spec] Upgrade to IEEE 754-2019 (#1050) (Andreas Rossberg) https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+/a221f25 TBR=ahaas@chromium.org,clemensh@chromium.org Change-Id: Id90c6e3228c4e5943e8bb49bc82fd4a9b01c424f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726578Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/a9a0d9b..496479d Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ff7e2eb..2568b37 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/57e1363..8215b08 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I54127742991c381ebbac0e8688f7dafe50621ac2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726577Reviewed-by:
-
Joran Siu authored
The s390 port uses the auxvector APIs to detect hardware/OS support for various z/Architecture features. These checks only make sense if we are running native, non-simulator mode. Moving the include<auxv.h> under V8_HOST_ARCH_S390 enables compilation of s390 simulation on platforms that do not have auxv.h header available. R=miladfar@ca.ibm.com,jyan@ca.ibm.com Change-Id: I685681a4f8786509beb181d8ae63876b3a4235b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726844Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Joran Siu <joransiu@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#62999}
-
