- 01 Nov, 2019 1 commit
-
-
Bartek Nowierski authored
A window is a Blink concept. This API marks the context as backing a detached window. This doesn't necessarily mean that the context is detached. Every time a JS function is called within a context that has a non-zero DetachedWindowReason, Runtime::kReportDetachedWindowAccess is invoked, which will report this call to Blink via a callback, which in turn can report number of such calls via UKM metrics. Bug: chromium:1018156 Change-Id: I67c89fef459f4efcb912229eed8a4f3ea3b60f54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862829 Auto-Submit: Bartek Nowierski <bartekn@chromium.org> Commit-Queue: Bartek Nowierski <bartekn@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64707}
-
- 30 Oct, 2019 1 commit
-
-
Gus Caplan authored
Change-Id: I2a1ad1835b751237b350e56d64e3475459bfb7a6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873715 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#64636}
-
- 29 Oct, 2019 1 commit
-
-
Andreas Haas authored
The new API with v8::BackingStore should be used instead as explained in https://docs.google.com/document/d/1sTc_jRL87Fu175Holm5SV0kajkseGl2r8ifGY76G35k This also relaxes the pre-condition for [Shared]ArrayBuffer::Detach to not require externalization first. Bug: v8:9380, v8:9908 Change-Id: Idd119fcd28be84a2fae74ae86f7381fd997766f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859628 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#64625}
-
- 28 Oct, 2019 1 commit
-
-
Anna Henningsen authored
The overload taking a `MicrotaskQueue*` was introduced in cce33f37 but never actually implemented. This aligns the constructor signature to actually work, and aligns it with e.g. `MicrotasksScope`. The previous signature without an `Isolate*` argument would not work, because there’s no pointer back from a MicrotaskQueue to the Isolate. Refs: https://chromium-review.googlesource.com/c/v8/v8/+/1414950 Bug: v8:8124 Change-Id: I5dbaabef54c8de2b48f6172808825a186971524d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879901Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64584}
-
- 24 Oct, 2019 1 commit
-
-
Anna Henningsen authored
Add an `array_buffer_allocator_shared` field to the `Isolate::CreateParams` struct that allows embedders to share ownership of the ArrayBuffer::Allocator with V8, and which in particular means that when this method is used that the BackingStore deleter will not perform an use-after-free access to the Allocator under certain circumstances. For Background: tl;dr: This is necessary for Node.js to perform the transition to V8 7.9, because of the way that ArrayBuffer::Allocators and their lifetimes currently work there. In Node.js, each Worker thread has its own ArrayBuffer::Allocator. Changing that would currently be impractical, as each allocator depends on per-Isolate state. However, now that backing stores are managed globally and keep a pointer to the original ArrayBuffer::Allocator, this means that when transferring an ArrayBuffer (e.g. from one Worker to another through postMessage()), the original Allocator has to be kept alive until the ArrayBuffer no longer exists in the receiving Isolate (or until that Isolate is disposed). See [1] for an example Node.js test that fails with V8 7.9. This problem also existed for SharedArrayBuffers, where Node.js was broken by V8 earlier for the same reasons (see [2] for the bug report on that and [3] for the resolution in Node.js). For SharedArrayBuffers, we already had extensive tracking logic, so adding a shared_ptr to keep alive the ArrayBuffer::Allocator was not a significant amount of work. However, the mechanism for transferring non-shared ArrayBuffers is quite different, and it seems both easier for us and better for V8 from an API standpoint to keep the Allocator alive from where it is being referenced. By sharing memory with the custom deleter function/data pair, this comes at no memory overhead. [1]: https://github.com/nodejs/node/pull/30044 [2]: https://github.com/nodejs/node-v8/issues/115 [3]: https://github.com/nodejs/node/pull/29637 Bug: v8:9380 Change-Id: Ibc2c4fb6341b53653cbd637bd8cb3d4ac43809c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874347 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#64542}
-
- 23 Oct, 2019 3 commits
-
-
Jakob Gruber authored
Previously, embedders had to fetch the 'exec' property off the RegExp prototype in order to call exec (and such calls involve two transitions between C++ and JS). This CL exposes a convenient RegExp::Exec method through the API. Bug: v8:9695 Change-Id: I57a9174626143d26f2ea34676b8e55fef64932cf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864940 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64508}
-
Jakob Gruber authored
Bug: v8:9695 Change-Id: I401a18c84a9ec1af7e14f44004a0788cbfd4a34b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864657Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64501}
-
Jakob Gruber authored
These counters track how often the slow path of these two builtins is hit. Exec is very permissive, its fast-path check doesn't look at the regexp prototype at all. Replace is strict; any change on the prototype will trigger the slow path. Chromium CL: https://crrev.com/c/1875250 Bug: v8:5577 Change-Id: I9807f43829981445b75b5c5d29800cbdac9bc26a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873698Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64496}
-
- 22 Oct, 2019 4 commits
-
-
Ulan Degenbaev authored
The new predicate indicates whether the backing store was created for an ArrayBuffer or a SharedArrayBuffer. It is useful for some embedders. Bug: v8:9380 Change-Id: I804063bb8c4c17815defd6538ce6a1b32f6a4531 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873689 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#64479}
-
Simon Zünd authored
This CL adds a boolean flag to Runtime.evaluate that allows REPL mode to be enabled. REPL mode hasn't landed in V8 yet, and the internal API for it is still in flux. R=yangguo@chromium.org Bug: chromium:1004193 Change-Id: I281285e225d3fd2dd4175f3dd967d6562459a203 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866510Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#64470}
-
Ulan Degenbaev authored
These are useful for the cases when an embedder works with backing stores without creating JS ArrayBuffer objects. Bug: v8:9380 Change-Id: I452bd911e7b20fb38568f18f9d15ea1a7ffb5a57 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1825339 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#64460}
-
Jakob Gruber authored
The natives blob was deprecated in V8 7.8. This CL removes all related functionality, including: - Build system support, i.e.: generation of natives_blob.bin and the v8_extra_library_files gn flag. - Related scripts (js2c.py, concatenate-files.py). - Related API functions (SetNativesDataBlob, InitializeExternalStartupData). - Natives bootstrapping logic. - The InternalArray type (previously exposed through natives). - Other natives-exposed builtins. - Inlining of these builtins. - The dedicated 'uncached external one byte string' type. Step 1 landed in https://crrev.com/c/1824944. Step 2 landed in https://crrev.com/c/1835536. Step 3 (this CL) removes these all functionality related to natives support in V8. Bug: v8:7624 Change-Id: Ice6c2662781efe8417231805276476d32bc5a625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844771 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Tamer Tas <tmrts@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#64446}
-
- 21 Oct, 2019 4 commits
-
-
Daniel Clark authored
Per spec, Module::SetSyntheticModuleExport should throw a ReferenceError when called with an export name that was not supplied when constructing that SyntheticModule. Instead, the current implementation crashes with a failed CHECK(). Add a new Module::SyntheticModuleSetExport that throws (without an ensuing crash) for this case, and deprecate the old Module::SetSyntheticModuleExport. Bug: v8:9828 Change-Id: I3b3d353064c3851882781818099bd8f6ee74c809 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860996Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64438}
-
Seth Brenith authored
On Windows ARM64, it is insufficient to just follow the linked list of frame pointers in all cases. This is similar to logic added in https://crrev.com/c/v8/v8/+/1701133 except this affects the Unwinder methods rather than the function metadata for RtlVirtualUnwind. Together with https://crrev.com/c/chromium/src/+/1844276 , this allows the Chromium unit test V8UnwinderTest.UnwindThroughV8Frames to pass on Windows ARM64. Change-Id: I82d4d894be14d4a6ace75bba10c13b10342d0b12 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1845189Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64432}
-
Clemens Backes authored
Before we can remove the deprecated methods, we need to provide default implementations for them. Then, we can remove all overrides in embedders, and finally remove the methods from v8. R=ulan@chromium.org CC=ahaas@chromium.org Bug: v8:9810 Change-Id: If9286dc8ba441c226c9a1d524832ff203ac4bce6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871915Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64419}
-
Clemens Backes authored
We still set a lot of macros depending on specific gcc versions. All these old versions are unsupported by now anyways, so we can also just define these macros as 1. If this CL sticks for a while, we can start actually cleaning up all code relying on these macros, as most of them should be 1 now on all platforms. R=ulan@chromium.org Bug: v8:9810 Change-Id: I2f9c55170091f8c263deeddfb7ff89e5b2a0bb12 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862564Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64413}
-
- 18 Oct, 2019 1 commit
-
-
Michael Lippautz authored
- Move foward deprecations in EmbedderHeapTracer - Deprecate SetFinalizationCallback in v8::TraceReference Change-Id: Ic68402096ce8f5fe08521253836d3b19d73326ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863941 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#64388}
-
- 17 Oct, 2019 3 commits
-
-
Toon Verwaest authored
This is a reland of c7c47c68. This makes TSAN happy in addition to: Previously I presumed that the context read from a frame in the profiler was a valid context. Turns out that on non-intel we're not guaranteed that the frame is properly set up. In the case we looked at, the profiler took a sample right before writing the frame marker indicating a builtin frame, causing the "context" pointer from that frame to be a bytecode array. Since we'll read random garbage on the stack as a possible context pointer, I made the code reading the native context from it a little more defensive. Bug: v8:9860 Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} Change-Id: I4d0ab4cbbb23a9ae616407f17ef8f35a0b68ddb4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864654 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64360}
-
Clemens Backes authored
TBR=machenbach@chromium.org CC=hablich@chromium.org No-Try: true Change-Id: I19512e953adce96c5d559e4552543fe2c11042d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863937Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64353}
-
Zhou, Zhiguo authored
This CL logs debug information of WASM in Intel VTune Amplifer via VTune's JIT Profiling API. With this CL, the profiling information of JITted code and its corresponding C/C++ source code is displayed optionally. To use this feature, a runtime flag "vtune_prof_annotat e_wasm" should be passed to the VTune-enabled V8 engine. Currently, the inline function in C/C++ is not well supported due to the limitation of source map. As a drive-by fix, the dynamically allocated event-specific data of JavaScript (src/third_party/vtune/vtune-jit.cc) is managed with C++ containers for safety. Change-Id: Ic27420fcdcd775bc5c7778abf5cff6edf0fb38b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782126Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Zhiguo Zhou <zhiguo.zhou@intel.com> Cr-Commit-Position: refs/heads/master@{#64351}
-
- 16 Oct, 2019 3 commits
-
-
Sathya Gunasekaran authored
This reverts commit c7c47c68. Reason for revert: breaks TSAN https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738 Original change's description: > Reland "[runtime] Move Context::native_context to the map" > > This is a reland of f05bae1e > > Previously I presumed that the context read from a frame in the profiler was > a valid context. Turns out that on non-intel we're not guaranteed that the > frame is properly set up. In the case we looked at, the profiler took a > sample right before writing the frame marker indicating a builtin frame, > causing the "context" pointer from that frame to be a bytecode array. Since > we'll read random garbage on the stack as a possible context pointer, I made > the code reading the native context from it a little more defensive. > > Bug: v8:9860 > > Original change's description: > > [runtime] Move Context::native_context to the map > > > > Remove the native context slot from contexts by making context maps > > native-context-specific. Now we require 2 loads to go from a context to the > > native context, but we have 1 field fewer to store when creating contexts. > > > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Reviewed-by: Maya Lekova <mslekova@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#64296} > > Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Auto-Submit: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64314} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9860 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64316}
-
Toon Verwaest authored
This is a reland of f05bae1e Previously I presumed that the context read from a frame in the profiler was a valid context. Turns out that on non-intel we're not guaranteed that the frame is properly set up. In the case we looked at, the profiler took a sample right before writing the frame marker indicating a builtin frame, causing the "context" pointer from that frame to be a bytecode array. Since we'll read random garbage on the stack as a possible context pointer, I made the code reading the native context from it a little more defensive. Bug: v8:9860 Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64314}
-
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}
-
- 15 Oct, 2019 4 commits
-
-
Adam Klein authored
Previous API owners (adamk, yangguo) are less-involved with the JS API then ever, so it seems appropriate to have an owner whose responsibility is squarely in the JS domain. Change-Id: I4235778fda8f55d0429e875d52ff74049024dad1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860328Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#64300}
-
Sathya Gunasekaran authored
This reverts commit f05bae1e. Reason for revert: broke arm sim debug https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/17714 https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8899519852984476944/+/steps/Check_-_trusted/0/logs/FunctionDetailsInlining/0 Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: Ie7b4086c3a9ab2627ecac599da36b20cf8d1f948 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863200Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64299}
-
Toon Verwaest authored
Remove the native context slot from contexts by making context maps native-context-specific. Now we require 2 loads to go from a context to the native context, but we have 1 field fewer to store when creating contexts. Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64296}
-
Michael Lippautz authored
Use v8::Data as basetype for managed objects that can integrate with v8::EmbedderHeapTracer. Bug: v8:9841 Change-Id: Id3e06701207a23870cea89e1d7d334c48fcd3006 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1856002Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#64283}
-
- 14 Oct, 2019 1 commit
-
-
Clemens Backes authored
It was marked V8_DEPRECATE_SOON in https://crrev.com/c/1261936 (part of M-71). R=ahaas@chromium.org, ulan@chromium.org Bug: v8:9810 Change-Id: I64a7937b518dbf2a75361bbbecd514618922d543 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1849523Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64273}
-
- 12 Oct, 2019 1 commit
-
-
Zhang, Shiyu authored
... for the case we haven't seen any elements on the entire prototype chain. Contributed by tao.pan@intel.com Change-Id: Ied7d1a918b545e71d94ab1521bf0d233ea15cfce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1848960Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> Cr-Commit-Position: refs/heads/master@{#64261}
-
- 11 Oct, 2019 1 commit
-
-
Clemens Backes authored
The API was marked to be depracated soon in https://crrev.com/c/1847366. Chromium switched to the new APIs in https://crrev.com/c/1855822. R=ulan@chromium.org Bug: v8:9810 Change-Id: I0befb06e180b57ec21ca4c2d56fa8e10a36b0d9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1856001Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64252}
-
- 10 Oct, 2019 1 commit
-
-
Clemens Backes authored
The flag is enabled since M-70, and we do not use the previous behaviour anywhere. Hence, remove the flag and clean up some API code. In particular, the concept of {TransferrableModule} is not needed any more, we can just use {CompiledWasmModule}. R=mstarzinger@chromium.org, adamk@chromium.org Bug: v8:9810 Change-Id: I9b3aa4972277a9262b58da70b141e90d1de31f35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847366 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64209}
-
- 09 Oct, 2019 4 commits
-
-
Igor Sheludko authored
Bug: v8:7703 Change-Id: If8605f4dc4ab50fb5a95b43994262c8f3edd92a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1849524Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#64192}
-
Clemens Backes authored
The method was deprecated in https://crrev.com/c/1581640 (part of M-76). R=ulan@chromium.org Bug: v8:9810 Change-Id: I08db459356273239f1d340b8792e2b57857d1076 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1849518Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64188}
-
Clemens Backes authored
The V8_HAS_DECLSPEC_NORETURN macro is unused since https://crrev.com/c/529072, where we switched to the standard [[noreturn]] attribute. R=ulan@chromium.org Bug: v8:9810 Change-Id: Ifd76c967df1da7bb71369e61cd0adc1807b62d44 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847365Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64175}
-
Clemens Backes authored
Since C++14, there is a spec'ed attribute for deprecation of methods, functions, types, aliases or anything else. This CL switches from the GCC __attribute__ to this standard attribute. This allows to use the V8_DEPRECATED and V8_DEPRECATE_SOON macros on anything where the standard attribute can be used (including {using} statements that were not working before). It also avoids the need to nest the whole declaration in the macro, making the code more readable. R=adamk@chromium.org Bug: v8:9810 Change-Id: I7adab7694af75423fb31ade2fc982dbf9c9bc699 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847361Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64174}
-
- 08 Oct, 2019 2 commits
-
-
Irina Yatsenko authored
Bug: chromium:1010312 Change-Id: I46ca9349f15f3dac896a4ab631be672c1979cc48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1838927 Commit-Queue: Irina Yatsenko <irinayat@microsoft.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#64167}
-
Ingvar Stepanyan authored
Unfortunately, codebase contains lots of places that use one of the two formats as an internal representation for Wasm locations: 1) {line: 0, column: byte offset within entire module} 2) {line: function index, column: byte offset within function} These places choose these formats interchangeably and convert from one to another depending on the presence of source map URL in Wasm. This is not very convenient and makes it hard to add support for DWARF which should behave just like Wasm with source maps - that is, report a raw Wasm script instead of fake scripts per each disassembled function, and use representation (1) instead of (2) internally. I tried to refactor these locations and avoid checking for source map URLs in the previous CL - https://crrev.com/c/v8/v8/+/1833688. However, it quickly got out of hand, and updating code in one place just kept revealing yet another that gets broken by the changes, so I made a decision to abandon it and leave to someone who knows the codebase better. Instead, this CL is based on https://crrev.com/c/v8/v8/+/1809375, but, rather than trying to integrate DWARF separately and only for supported agents, it pretends that encountering DWARF section is the same as encountering a `sourceMappingURL` section with fake URL "wasm://dwarf". This ensures that Wasm with DWARF behaves exactly in the same way as Wasm with source maps, just like we want, with minimal changes to the codebase. The only downside is that frontends without DWARF support won't get even a disassembled version of Wasm that contains DWARF info. This is unfortunate, but, as per previous discussions, should be fine given current state of Wasm debugging. Change-Id: Ia7256075e4bfd2f407d001d02b96883d7267436e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1834341 Commit-Queue: Ingvar Stepanyan <rreverser@google.com> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64157}
-
- 07 Oct, 2019 2 commits
-
-
Michael Lippautz authored
TracedGlobalTrait was unable to override v8::TracedGlobal<v8::Object> for avoiding the destructor because it is needed on the API surface itself and C++ ODR which prohibits specialization after template instantiation. Avoid this problem by providing a separate type TracedReference that, similar to TracedGlobal, is purely traced but avoids the destructor completely. This only works for embedders that have their memory management tied to V8 as it is prone to accessing already reclaimed objects otherwise. Bug: chromium:995684 Change-Id: Iab4332ed417b26c58638a8f9389174cc355a305b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1840972 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#64150}
-
Igor Sheludko authored
With the smi-corrupting decompression approach we don't have to sign extend Smis anymore and therefore we can switch to zero extending approach by moving the isolate root to the beginning of the reserved 4Gb region. Bug: v8:9706 Change-Id: Icd6008fa87d0924519b574fdec445976f742e306 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1835548 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64144}
-
- 04 Oct, 2019 1 commit
-
-
Michael Lippautz authored
Change-Id: I0751c1761a2d07dd89d831ca6370ae01bc569b6a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1841351 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#64116}
-