This was triggered by the inspector fuzzer, which terminates execution
after two seconds. This is done by triggering a termination exception
via an interrupt. In this case, the runtime function should return
immediately, and return the exception sentinel.
This CL fixes the WasmDebugBreak runtime function to do that correctly.
R=thibaudm@chromium.org
Bug: chromium:1215711
Change-Id: Idf8e9769809f135b426e4d1a0ef82fae826050b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041423
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75838}
This reverts commit 0cd8a913a7.
Reason for revert: There are reports of this check failing.
It's still unclear why it's failing and what the implications of
that are. The check had been disabled for many years so it seems
safe to disable it again for now (it's in --debug-code anyways).
Original change's description:
> [ia32] Restore FP stack check in the deoptimizer
>
> This restores the check that was removed in
> https://chromiumcodereview.appspot.com/12300020/
>
> Bug: chromium:736643
>
> Change-Id: I82e218b9f2572953a7f433d713dff0528574eea1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848469
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74168}
Bug: chromium:1208057
Change-Id: I2f8ecfca3f4732583378a5d5b2a38ad636914e1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041673
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75837}
This reverts commit e24fa91327.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/18917/overview
Original change's description:
> [offthread] Template deserializer on Isolate
>
> Make the deserializer class templated on Isolate/LocalIsolate. This
> allows the ObjectSerializer to be split into a main-thread and offthread
> variant, with the latter taking a LocalIsolate.
>
> Eventually, we probably want to anyway split off the code-cache de/serializer
> to a separate implementation (for various reasons), and this the only one that
> wants off-thread finalization, and at this point the deserializer can revert
> back to being un-templated, used only for bootstrapping. However, this is the
> simplest way, for now, to enable off-thread deserialization.
>
> Bug: chromium:1075999
> Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75834}
Bug: chromium:1075999
Change-Id: Id699ebe0c17d3a61ec35b0f78417306175271647
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041675
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75836}
Currently deopt fuzzer passes --future and so should skip the same tests
as the future variant.
BUG=v8:9684
Change-Id: I3d10dae7ba7cffc36bd4777941ac053c42c80cef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041668
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75835}
Make the deserializer class templated on Isolate/LocalIsolate. This
allows the ObjectSerializer to be split into a main-thread and offthread
variant, with the latter taking a LocalIsolate.
Eventually, we probably want to anyway split off the code-cache de/serializer
to a separate implementation (for various reasons), and this the only one that
wants off-thread finalization, and at this point the deserializer can revert
back to being un-templated, used only for bootstrapping. However, this is the
simplest way, for now, to enable off-thread deserialization.
Bug: chromium:1075999
Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75834}
The JSFunction::set_context call happens 1. only on script functions
and 2. before the function is executed, and therefore the compiler
only ever sees the final value.
Bug: v8:7790
Change-Id: I618673c7ec6284dcf3d80b1edd7be516b048ed2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041664
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75833}
This also fixes a little mistake from
https://chromium-review.googlesource.com/c/v8/v8/+/2992914.
The label must be far here.
Change-Id: Ie53cb3713b1b5db6c10e4ce6ed177a510da847f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3031897
Reviewed-by: Brice Dobry <brice.dobry@futurewei.com>
Reviewed-by: Ji Qiu <qiuji@iscas.ac.cn>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Ji Qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/master@{#75832}
With lazy feedback allocation we don't tier up to baseline early. This
test requires us to tier up to baseline. So add
--lazy_feedback_allocation as a required flag.
Bug: v8:12009
Change-Id: Ibbc1d1cc74ae368ef414f513a0cd46e9bf068186
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3042718
Commit-Queue: Mythri Alle <mythria@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75829}
This makes the V8 dcheck control independent of Chromium's and
prepares switching Chromium's default behavior without affecting V8
developers or builders.
Preparation for: https://crrev.com/c/2893204
Bug: chromium:1225701
Change-Id: I520b96019b04196f4420716ff3500ebd6c21666f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038528
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75827}
... which will update both the CodeObjectSlot contents and the cached
value of the code entry point when the pointed Code object is
evacuated.
This is done by introducing an OLD_TO_CODE remembered set which is
populated with the recorded slots containing pointers to Code objects.
CodeDataContainer is the only kind of holder that can contain Code
pointers, so having a CodeObjectSlot is enough to compute the holder
CodeDataContainer object and update the cached code entry point there.
This CL fixes the data race in the previous implementation which were
updating the code entry point during Code object migration.
Bug: v8:11880
Change-Id: I44aa46af4bad7eb4eaa922b6876d5f2f836e0791
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035084
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75826}
Avoiding the builtin call, and potentially enabling other Turbofan
optimizations to apply.
This required teaching the MemoryLowering pass how to produce
Wasm-style isolate-independent code, where external references won't
work, and builtin calls have to be encoded differently.
Bug: v8:7748
Change-Id: Ib6d87da644330e7c3623c11aa333b23074aeae19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038524
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75824}
Earlier CL: https://chromium-review.googlesource.com/c/v8/v8/+/3030711
used esi register to load code object. When we use CallRuntime we
expect esi to contain Context object. So, restore this value from
the frame before calling into runtime.
Bug: chromium:1230936
Change-Id: I1f34aa85ff77555c5cbbe2d5b5401056b36278af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041425
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75822}
Hashing FunctionSigs can be quite expensive for large modules;
luckily in some cases we can avoid doing that work.
Change-Id: Ia18060b4c27ab34b44bda4bb81ea05299ecb0f49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038523
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75819}
This CL fixes a previous change in String.prototype.startsWith which
didn't throw an exception (in the optimized version) when `undefined`
was passed as a receiver and the search string was the empty string.
Bug: chromium:1230260
Change-Id: I835bd409b09b78bf7235c77596f62b588c95611d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040841
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75818}
Most Torque-defined extern classes already use @generateCppClass. As
Nico pointed out in [1], it would be nice to convert the remaining
classes and remove this option. This change converts most of those
remaining classes. I know that the future of Torque-defined classes is a
subject of some debate right now, but I think that it's worth doing a
few mechanical changes to reduce the existing variety of options.
Changes that don't exactly follow the usual pattern:
1. BigIntBase, MutableBigInt: we can define these without a body, and
then Torque treats them as "really external" rather than "kind of
external, but with some Torque-generated parts".
2. RegExpMatchInfo: moved its inline functions into a separate file,
which the generated -tq.cc file requires.
[1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit#
Bug: v8:8952
Change-Id: I84c7958a295caa0bab847683c05022e18c921cad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027742
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#75817}
All these methods are called in compiler/concurrent contexts and
should therefore use refs where possible. This mostly just pushes code
around, but does avoid a few completely unnecessary ref-handle-ref
round-trips.
Bug: v8:7790
Change-Id: I18e6f45ddcd16373b5349bdb7d2dccd205f5c9ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038522
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75814}
This means we only have to maintain the arch list in one place.
Bug: v8:11420, v8:11421
Change-Id: I1618e2ab1396ad85aca60923111e5966e547e65a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041420
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75813}
If any logging is enabled (for instance with --prof), the calls into
Logger:ApiEntryCall become quite expensive.
Move the FLAG_log_api checks to the header to speed up these
high-frequency events.
Change-Id: Iba718c856cd57a890ad6b63bcf4b6836bfd5d3f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024156
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75812}
With -Wimplicit-fallthrough enabled, ittapi fails to compile on
V8 Linux Vtune bot due to a missing fallthrough annotation:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20vtunejit/43006/overview
Updating ittapi to latest version 3.18.13 to get the fix for that.
Change-Id: Iaa98ca6b893ec43ee6396e57df9948313d7b36cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040846
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75811}
This is a reland of ea55438a53. Relanding
after a fix lands here:
https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures
were caused because baseline code could be flushed during the process
of deoptimization after we choose which entry (InterpreterEnterAt* /
BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect
baseline code but it could be flushed before we execute the builtin. The
fix is to defer the decision.
Original change's description:
> [sparkplug] Support bytecode / baseline code flushing with sparkplug
>
> Currently with sparkplug we don't flush bytecode / baseline code of
> functions that were tiered up to sparkplug. This CL adds the support to
> flush baseline code / bytecode of functions that have baseline code too.
> This CL:
> 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
> JSFunction as a custom weak pointer where the code is treated as weak if
> the bytecode corresponding to this function is old.
> 2. Updates GC to handle the functions that had a weak code object during
> the atomic phase of GC.
> 3. Updates the check for old bytecode to also consider when there is
> baseline code on the function.
>
> This CL doesn't change any heuristics for flushing. The baseline code
> will be flushed at the same time as bytecode.
>
> Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
> Bug: v8:11947
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75674}
Bug: v8:11947
Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75810}
This is a reland of 431fff66f5.
The fix is in BUILD.gn: We need to also include chromeos, which is a
linux target which is not covered by "is_linux" in gn.
R=ahaas@chromium.org
Original change's description:
> [traphandler] Add simulator support
>
> This prepares the trap handler to support being used from simulators.
> Modifications to the arm64 simulator will be done in a follow-up CL. For
> now, the trap handler will be registered but not used in Wasm (we emit
> explicit bounds checks instead, as before).
>
> The implementation uses inline assembly, so it is only available on x64
> POSIX systems for now. This is the main platform we use for testing and
> for fuzzing, so it should give us the test coverage we need. If needed,
> inline assembly for other platforms can be added later.
> The new code will be executed by the existing arm64 simulator bots, e.g.
> "V8 Linux - arm64 - sim".
>
> R=ahaas@chromium.org, mseaborn@chromium.org
>
> Bug: v8:11955
> Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75780}
Bug: v8:11955
Change-Id: I8af39dea5b2cd3fa5418170a458832b3d6075107
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040844
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75809}
The x64 binary will work with Rosetta, but not requiring
Rosetta is nicer.
Change-Id: I34f9e5304022c33ffd3bac5ae881bd4d94681356
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038529
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75808}
Intel Optimization Manual update the suggestion for code alignment from 16B to 16B(for codes in legacy decoded pipeline) and 64B (for codes in Decoded Icache).
Since the loop often goes to the Decoded Icache, so align the loop header at 64B.
Change-Id: I1092e6dd5ea5937d5512865ce847ee00d1e8cb21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017311
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75807}
.. instead of handles and update all uses. Likewise with
ElementAccessInfo. Essentially, this creates the needed refs up-front
and removes useless MakeRef calls from PAI users.
Bug: v8:7790, v8:11671
Change-Id: I175e77dcca27760101606587de615e3497e68c68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3030701
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75805}
.. and explicitly mark behavior through tags/naming conventions:
// This method is never called when concurrent inlining is enabled.
void SerializeFoo(NotConcurrentInliningTag);
// This method is thread-safe and may be called at any time.
void CacheBar();
It turns out that all our remaining SerializeFoo methods are already
either of the former or latter category and thus do not block removal
of the serialization phase for concurrent inlining.
Bug: v8:7790
Change-Id: If8f3bc2e407bc2824f83bfcd1f520f3b14dc58ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3026709
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75804}
GC may change heap state and make this dependency fail. That's okay -
it passed once before, meaning that compilation saw a self-consistent
JSFunctionRef state.
Bug: chromium:1230930
Change-Id: I367b10e4aa88101f1ca83a46f596c5f289f6cab2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040838
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75802}
An object got allocated as part of a parameter expression, which may
have caused GC issues.
R=bmeurer@chromium.org
Bug: chromium:1230041
Change-Id: I94537db7d0be5200049fbc6bd3eda0d49b6d7c17
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038525
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75801}
This reverts commit 431fff66f5.
Reason for revert: Causes link error in chrome: https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20ChromiumOS%20MSan%20Builder/24667/overview
Original change's description:
> [traphandler] Add simulator support
>
> This prepares the trap handler to support being used from simulators.
> Modifications to the arm64 simulator will be done in a follow-up CL. For
> now, the trap handler will be registered but not used in Wasm (we emit
> explicit bounds checks instead, as before).
>
> The implementation uses inline assembly, so it is only available on x64
> POSIX systems for now. This is the main platform we use for testing and
> for fuzzing, so it should give us the test coverage we need. If needed,
> inline assembly for other platforms can be added later.
> The new code will be executed by the existing arm64 simulator bots, e.g.
> "V8 Linux - arm64 - sim".
>
> R=ahaas@chromium.org, mseaborn@chromium.org
>
> Bug: v8:11955
> Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75780}
Bug: v8:11955
Change-Id: I74d2e41864fc515bd9727898f12ec1498b97ee62
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040839
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#75798}
Rolling v8/base/trace_event/common: d5bb24e..d41864d
Rolling v8/build: fd86d60..33763d1
Rolling v8/buildtools/linux64: git_revision:b2d77ab1373192d1532af94b68fb8bab727b0e5b..git_revision:61a0153b5e60f11100a04e51393cae15268d1ee3
Rolling v8/buildtools/third_party/libc++abi/trunk: 7d5c92f..e8bf577
Rolling v8/third_party/aemu-linux-x64: eghzU3LI6jsGYPkSzAoCDHeiVyaydZjwxB5kjkPImaMC..XSfC0vpqwj2Qzz0hAfMHYCCe5KDFiXqzb4M3U-cT6i4C
Rolling v8/third_party/logdog/logdog: 88ab863..17ec234
Rolling v8/tools/luci-go: git_revision:d10ff2af1182ccaad573bc5acb84a36f4c280876..git_revision:6387586e5b3279aebdf22bdab7ae619dbc156b66
Rolling v8/tools/luci-go: git_revision:d10ff2af1182ccaad573bc5acb84a36f4c280876..git_revision:6387586e5b3279aebdf22bdab7ae619dbc156b66
Rolling v8/tools/luci-go: git_revision:d10ff2af1182ccaad573bc5acb84a36f4c280876..git_revision:6387586e5b3279aebdf22bdab7ae619dbc156b66
TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: Icb2300e3fddbb5c8550312216de5daedde164221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040126
Reviewed-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@{#75797}
I've noticed a few places where class fields as defined in Torque have
different names than the corresponding accessors in the C++ class. I
think they should match. Most of this change is just mechanically
updating the various places that use k##Field##Offset for those fields.
Change-Id: I8ba52aed7f6a1cd6b2d71158f71150b66c2c0da0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027263
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75796}
On Aix, thread_cputime and clock_gettime (with CLOCK_THREAD_CPUTIME_ID)
can both be used to get time consumed by a thread. However,
thread_cputime is preferable, as it is has better resolution
(nanoseconds vs 10ms for clock_gettime).
Change-Id: I8a698f85defa011f6ed1eb5f47a6dbd4e21d1f67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3036281
Commit-Queue: Vasili Skurydzin <vasili.skurydzin@ibm.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75793}
Bug: v8:7790
Change-Id: I5d9815f479bc009d280595cf0dac75dea17c3738
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024339
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75790}
This wraps up the transition away from kSerialized ref kinds.
Since JSFunctionRef is a complex type, we don't attempt full
consistency on the background thread. Instead, we serialize functions
on the background in a partially-racy manner, in which consistency
between different JSFunction fields is *not* guaranteed. Consistency
is later verified through a new compilation dependency kind during
finalization.
Bug: v8:7790, v8:12004
Change-Id: Ic2b78af9c9fe183c8769d323132bb304b151dc75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968404
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75789}
