Skip to content

V
V8
Switch branch/tag
  1. 11 Feb, 2021 2 commits
    • Clemens Backes's avatar
      Revert "[wasm] Send a single scriptParsed event per script" · 724b2eb4
      Clemens Backes authored 
      This reverts commit b471bc93.

Reason for revert: Seems like we don't reliably deliver scriptParsed events on reload after this CL.

Original change's description:
> [wasm] Send a single scriptParsed event per script
>
> If a script was shared between multiple modules (because they used the
> same wire bytes) it could happen that we still triggered multiple
> "scriptParsed" events via CDP. This was because
> {WasmEngine::GetOrCreateScript} did not communicate back whether it
> used a cached script or whether it created a new one.
>
> This CL moves the call to {Debug::OnAfterCompile} (which triggers the
> "scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method,
> such that we only call it once per script.
> Since the engine only holds a weak reference to the script, we would
> still trigger multiple events if the script is garbage-collected in the
> meantime. In this case there is no way around this, as the new script
> would have a new ID, hence we need to emit a new event to make it
> public to the debugger.
>
> R=​thibaudm@chromium.org
> CC=​bmeurer@chromium.org
>
> Bug: chromium:1151211
> Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72648}

TBR=clemensb@chromium.org,bmeurer@chromium.org,thibaudm@chromium.org

Change-Id: I6cc299734e4fcff29289355973e7660b60b49a25
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1151211
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689199Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72667}
      724b2eb4
    • Clemens Backes's avatar
      [wasm] Send a single scriptParsed event per script · b471bc93
      Clemens Backes authored 
      If a script was shared between multiple modules (because they used the
same wire bytes) it could happen that we still triggered multiple
"scriptParsed" events via CDP. This was because
{WasmEngine::GetOrCreateScript} did not communicate back whether it
used a cached script or whether it created a new one.

This CL moves the call to {Debug::OnAfterCompile} (which triggers the
"scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method,
such that we only call it once per script.
Since the engine only holds a weak reference to the script, we would
still trigger multiple events if the script is garbage-collected in the
meantime. In this case there is no way around this, as the new script
would have a new ID, hence we need to emit a new event to make it
public to the debugger.

R=thibaudm@chromium.org
CC=bmeurer@chromium.org

Bug: chromium:1151211
Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72648}
      b471bc93
  3. 03 Feb, 2021 1 commit
  5. 27 Jan, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Fix data race in lazy compilation · 591db5d9
      Clemens Backes authored 
      Instead of updating the detected features set directly, use the
synchronized {OnCompilationStopped} method.
In order to avoid this error in the future, the whole
{detected_features()} getter is removed, as it returns a pointer which
can only be accessed when holding the mutex anyway. Also, the refactored
code was the only user of this dangerous method.

Drive-by: Pass the WasmFeatures set by value, since it's just an
EnumSet.
Drive-by 2: Remove a print line from the regression test which can be
confusing if the test is picked up again by foozzie.

R=ahaas@chromium.org
CC=zhin@chromium.org

Bug: v8:11357
Change-Id: I75b5c8f35983d2bc1fd2b61adcb2ecfc18564f39
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653226Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72375}
      591db5d9
  7. 26 Jan, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Fix tier down on streaming with error · c5c5d144
      Clemens Backes authored 
      Recompilation for tier down should not be triggered if the module had a
compile error. This CL ensures that by moving the recompilation a bit
later in the async compilation, to a place where a compile error would
have been detected already. An added DCHECK would catch similar bugs
earlier (crashing instead of timing out).

R=ahaas@chromium.org

Bug: chromium:1160031
Change-Id: I7eb3d2921db0f28bb39e9ec6150fd98fd4b99089
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649028
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72329}
      c5c5d144
  9. 20 Jan, 2021 2 commits
  11. 19 Jan, 2021 3 commits
  13. 12 Jan, 2021 1 commit
  15. 07 Jan, 2021 3 commits
  17. 15 Dec, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Initialize compile job early · f3682984
      Clemens Backes authored 
      Since the compile job can always be reused after creation (even if it
runs out of work), we do not need the logic to (re-)initialize it. In
fact, it will always only be initialized once already.
This allows us to initialize it once during construction of the
compilation state (or right after the initialization), and then access
it without locks later.

In addition, this CL
1) renames "current_compile_job_" to "compile_job_", since there will
   always only be one now;
2) removes the {ScheduleCompileJobForNewUnits} method, and just does a
   {compile_job_->NotifyConcurrencyIncrease()} instead;
3) removes the {has_priority_} field and just directly does a
   {compile_job_->UpdatePriority} call.

The streaming test platform needed to be fixed to avoid calling {Join}
on the job handle, which would invalidate the handle afterwards.
Instead, we just run all tasks as long as there are any.

R=thibaudm@chromium.org
CC=etiennep@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: I7094231e86d5f54cfca5e971b96fd81e994c874a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584946
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71757}
      f3682984
  19. 10 Dec, 2020 2 commits
  21. 08 Dec, 2020 4 commits
    • Clemens Backes's avatar
      Reland "[wasm] Pass the script ID to code logging" · a58a5e59
      Clemens Backes authored 
      This is a reland of ab4d9717.
The original CL did a std::move before the final use of the NativeModule.
PS2 removes that.

TBR=petermarshall@chromium.org, thibaudm@chromium.org

Original change's description:
> [wasm] Pass the script ID to code logging
>
> We didn't pass a script ID with the code creation events for profiling.
> This made DevTools lose the connection to the wasm script, hence
> jumping from the profiler entry to the source did not work.
>
> This CL changes the timing of code logging a bit such that the script is
> always allocated before logging. In the queue of code to be logged we
> then also store the script ID, and finally set it on the {CodeEntry}
> object.
>
> R=thibaudm@chromium.org
>
> Bug: chromium:1125986
> Change-Id: I2248c1d520bc819436bbe732373f7a3446b64f48
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575057
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71654}

Bug: chromium:1125986
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Change-Id: I2a7c5fe04fff726836b1279e3d05b1702a4efb76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2578980Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71663}
      a58a5e59
    • Etienne Pierre-doray's avatar
      Reland "Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."" · fc1d6f35
      Etienne Pierre-doray authored 
      This is a reland of 064ee3c8

Issue 1: WasmEngine UAF when CompilationState is destroyed
asynchronously
Fix: Include https://chromium-review.googlesource.com/c/v8/v8/+/2565508
in this CL. Use OperationBarrier to keep WasmEngine alive.

Issue 2: In gin, JobTask lifetime is not extended beyond
JobHandle, thus making CancelAndDetach unusable.
This is fixed in chromium here:
https://chromium-review.googlesource.com/c/chromium/src/+/2566724

Original change's description:
> Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."
>
> Reason for revert: Data race:
> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121
>
> It was assume that MockPlatform runs everything on 1 thread. However,
> MockPlatform::PostJob previously would schedule the job through
> TestPlatform, which eventually posts concurrent tasks, thus causing
> data race.
> Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform
> ensures the jobs also run sequentially.
>
> Additional change:
> - CancelAndDetach is now called in ~CompilationStateImpl() to make sure
> it's called in sequence with ScheduleCompileJobForNewUnits
>
> Original CL description:
> To avoid keeping around a list of job handles, CancelAndDetach() is
> used in CancelCompilation. Dependency on WasmEngine is handled by a
> barrier that waits on all jobs to finish.
>
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Original-Commit-Position: refs/heads/master@{#71074}
> Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71459}

TBR=ulan@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: I6175092c97fea0d5f63a97af232e2d54cccea535
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569360
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71662}
      fc1d6f35
    • Clemens Backes's avatar
      Revert "[wasm] Pass the script ID to code logging" · 8d013ea1
      Clemens Backes authored 
      This reverts commit ab4d9717.

Reason for revert: UBSan issues: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/14184/overview

Original change's description:
> [wasm] Pass the script ID to code logging
>
> We didn't pass a script ID with the code creation events for profiling.
> This made DevTools lose the connection to the wasm script, hence
> jumping from the profiler entry to the source did not work.
>
> This CL changes the timing of code logging a bit such that the script is
> always allocated before logging. In the queue of code to be logged we
> then also store the script ID, and finally set it on the {CodeEntry}
> object.
>
> R=​thibaudm@chromium.org
>
> Bug: chromium:1125986
> Change-Id: I2248c1d520bc819436bbe732373f7a3446b64f48
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575057
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71654}

TBR=petermarshall@chromium.org,clemensb@chromium.org,thibaudm@chromium.org

Change-Id: I03c90c77b55e770797a6d66b1d778992a047e07a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1125986
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575070Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71660}
      8d013ea1
    • Clemens Backes's avatar
      [wasm] Pass the script ID to code logging · ab4d9717
      Clemens Backes authored 
      We didn't pass a script ID with the code creation events for profiling.
This made DevTools lose the connection to the wasm script, hence
jumping from the profiler entry to the source did not work.

This CL changes the timing of code logging a bit such that the script is
always allocated before logging. In the queue of code to be logged we
then also store the script ID, and finally set it on the {CodeEntry}
object.

R=thibaudm@chromium.org

Bug: chromium:1125986
Change-Id: I2248c1d520bc819436bbe732373f7a3446b64f48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575057
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71654}
      ab4d9717
  23. 02 Dec, 2020 2 commits
    • Clemens Backes's avatar
      [wasm][cleanup] Rename an "offset" parameter · a9bb380c
      Clemens Backes authored 
      From reading the code it was totally unclear what the purpose of the
"offset" parameter at ProcessCodeSectionHeader and CheckFunctionsCount
is. Actually, it's just there for setting an error position. Thus this
CL renames the field, and a related local variable to make the use more
clear.

Drive-by: Remove a confusing and unnecessary Decoder::Reset call.

R=ahaas@chromium.org

Change-Id: Iccde5ccb3b9e7e52976c47724157c184fd345ec4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567709Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71563}
      a9bb380c
    • Clemens Backes's avatar
      Revert "Reland [wasm] Reduce job priority once baseline compilation finishes" · d7859a0a
      Clemens Backes authored 
      This reverts commit 83d289b8.

Reason for revert: lock order inversion, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/12584/overview

Original change's description:
> Reland [wasm] Reduce job priority once baseline compilation finishes
>
> ReduceCompilationPriority takes a lock now.
>
> Original message:
> This Cl changes the priority of baseline compilation from kUserVisible
> to kUserBlocking. Once baseline compilation finishes, the priority is
> reduced to kUserVisible. The reason for using kUserBlocking is that
> thereby TurboFan compilation cannot block Liftoff compilation anymore.
> Additionally, kUserBlocking is quite appropriate, as the initial
> compilation does block a whole section of a web app from execution.
>
> R=​clemensb@chromium.org
>
> Bug: v8:11088
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Change-Id: I6e1bcc809148198a4b4f88bfd4f2e62b1b061439
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563675
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71546}

TBR=ahaas@chromium.org,clemensb@chromium.org

Change-Id: I62e4e3d0663dbd181b14f77f0c1586d5e503f324
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11088
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567953Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71557}
      d7859a0a
  25. 01 Dec, 2020 2 commits
    • Andreas Haas's avatar
      Reland [wasm] Reduce job priority once baseline compilation finishes · 83d289b8
      Andreas Haas authored 
      ReduceCompilationPriority takes a lock now.

Original message:
This Cl changes the priority of baseline compilation from kUserVisible
to kUserBlocking. Once baseline compilation finishes, the priority is
reduced to kUserVisible. The reason for using kUserBlocking is that
thereby TurboFan compilation cannot block Liftoff compilation anymore.
Additionally, kUserBlocking is quite appropriate, as the initial
compilation does block a whole section of a web app from execution.

R=clemensb@chromium.org

Bug: v8:11088
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: I6e1bcc809148198a4b4f88bfd4f2e62b1b061439
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563675
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71546}
      83d289b8
    • Etienne Pierre-Doray's avatar
      Revert "Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."" · 393782ef
      Etienne Pierre-Doray authored 
      This reverts commit 064ee3c8.

Reason for revert: Causing blink_web_tests to fail on builder "WebKit Linux MSAN"
https://bugs.chromium.org/p/chromium/issues/detail?id=1153968

Original change's description:
> Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."
>
> Reason for revert: Data race:
> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121
>
> It was assume that MockPlatform runs everything on 1 thread. However,
> MockPlatform::PostJob previously would schedule the job through
> TestPlatform, which eventually posts concurrent tasks, thus causing
> data race.
> Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform
> ensures the jobs also run sequentially.
>
> Additional change:
> - CancelAndDetach is now called in ~CompilationStateImpl() to make sure
> it's called in sequence with ScheduleCompileJobForNewUnits
>
> Original CL description:
> To avoid keeping around a list of job handles, CancelAndDetach() is
> used in CancelCompilation. Dependency on WasmEngine is handled by a
> barrier that waits on all jobs to finish.
>
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Original-Commit-Position: refs/heads/master@{#71074}
> Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71459}

TBR=ulan@chromium.org,jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,etiennep@chromium.org
Bug: chromium:1153968, v8:11209, v8:11210, v8:11212

# Not skipping CQ checks because original CL landed > 1 day ago.

Change-Id: I2c8406bea81ee7cf6c5726c2fec50fffdce09611
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566446Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71519}
      393782ef
  27. 30 Nov, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Pass correct code section start in streaming compilation · 7bace1d4
      Clemens Backes authored 
      The streaming decoder computed the code section start from the passed
"offset". That offset is computed from the module offset *after* the
number of functions has been read. Hence 1 is subtracted, with the
comment:
// The offset passed to {ProcessCodeSectionHeader} is an error offset and
// not the start offset of a buffer. Therefore we need the -1 here.

That subtraction of 1 worked when the number of functions was encoded in
a 1-byte LEB, otherwise it was off.

This CL fixes the immediate issue of passing the right code offset. The
usage of the previously existing offset also seems wrong, and I will try
to clean that up in a follow-up CL.

R=ahaas@chromium.org
CC=szuend@chromium.org

Bug: chromium:1150303
Change-Id: I64bb2ececeb4749b7ba2096cd148ccb4079eca4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562383
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71503}
      7bace1d4
  29. 27 Nov, 2020 1 commit
  31. 26 Nov, 2020 1 commit
  33. 25 Nov, 2020 2 commits
  35. 24 Nov, 2020 1 commit
  37. 20 Nov, 2020 2 commits
  39. 11 Nov, 2020 2 commits
    • Clemens Backes's avatar
      [wasm][cleanup] Avoid data race on has_priority_ field · 424e7a06
      Clemens Backes authored 
      After https://crrev.com/c/2529140, the actual data race should already
be fixed. This CL updates documentation (by moving the field to the
fields protected by {mutex_}), and updates {SetHighPriority} to also
take the mutex. This change is not strictly necessary, because this
method is only called right after creating the object, so no other
threads have access to it yet. But relying on that seems brittle, and
moving the initialization to the constructor is a bigger refactoring
that I don't consider worth it at the moment. The whole priority
management will probably be refactored again soon anyway.

R=ahaas@chromium.org

Bug: v8:11141
Change-Id: I496b619d551aeb584bd6e777c04ed4df076c3ae9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529143Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71113}
      424e7a06
    • Clemens Backes's avatar
      [wasm] Make a DCHECK stricter · e02cfac6
      Clemens Backes authored 
      The message on the DCHECK says that no compilation should have started
when adding js-to-wasm units, but the check itself then also allows for
situations where the job was created but is already done. This is
unnecessarily permissive.
This CL fixes the DCHECK to check what the comment says.

R=ahaas@chromium.org

Change-Id: I6de8af33869fd11ae91ce2009c360b8d4ed54e9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529142Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71111}
      e02cfac6
  41. 10 Nov, 2020 3 commits
  43. 09 Nov, 2020 1 commit
  45. 06 Nov, 2020 1 commit