-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathcommits.txt
More file actions
4782 lines (3824 loc) · 199 KB
/
commits.txt
File metadata and controls
4782 lines (3824 loc) · 199 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
commit b9fa77b45d0f7d7d4847d60361621e1573cac9bb
Author: Dominik Inführ <dinfuehr@chromium.org>
Date: Fri May 24 12:03:30 2024 +0200
[heap] Move marking bit into separate byte for traced handles
This CL moves the markbit from the flags_ field into a separate
boolean field. This should not regress the size of TracedNode on
either 32- or 64-bit architectures as we still use 2 words for a
TracedNode. With this change the flags are now main thread only and
do not need use atomic accesses anymore.
This CL should also fix a data race where is_in_use() was used
non-atomically in a DCHECK while the concurrent marker set the mark
bit concurrently.
Bug: 340789840
Change-Id: I73fa6e9cc22fa3a6fc1d54922114911f9bb0db3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5569191
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94072}
commit f426e631e07945be2ba69dca0778801c1f976e80
Author: Clemens Backes <clemensb@chromium.org>
Date: Thu Apr 4 15:26:35 2024 +0200
Reland "[wasm] Also cache smaller code, after 2s delay"
This is a reland of commit 27a0f364839889c194cb083cb4c1cd32c1ad284f.
We now set the hard threshold in more tests to trigger immediate
caching and avoid data races.
Original change's description:
> [wasm] Also cache smaller code, after 2s delay
>
> Finch experimentation showed that all more aggressive caching strategies
> improve hit rates dramatically. We have to balance that against
> increased time for serializing the module though.
> Reducing the hard threshold results in pauses during background
> compilation, hence we keep that at 1MB and additionally cache after 1kB
> of new Turbofan code has been compiled, but no new code within 2
> seconds.
>
> The latter two numbers don't seem to matter too much, but when
> increasing the delay too much we see an increase of serialization
> times on the highest percentiles, so keep it pretty low. This also
> ensures that we still cache something if the user navigates away
> after a few seconds.
>
> R=ahaas@chromium.org
>
> Bug: v8:14411
> Change-Id: I67398acec39d29331fbd2428eec2f9387eeeb26a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5412938
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#93156}
Bug: v8:14411
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_dbg
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Change-Id: I30acd82f94147c06646c0eca4e79a6ccc20b9102
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5423428
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93170}
commit 80aef2091884c9cdec53f552e8c226ef87261285
Author: Andreas Haas <ahaas@chromium.org>
Date: Wed Mar 20 15:47:46 2024 +0100
[test][asmjs] Avoid data race in test by increasing sampling interval
There seems to be a data race in the CPU profiler when two samples get
collected at the same time. This happens in tests where samples get
collected explicitly through a test API, in addition to the samples that
get collected periodically by the profiler.
With this CL we increase the sampling interval of the profiler, so that
the test finishes before the profiler wants to collect its sample.
This CL also reverts a fix that was attempted before but does not, as
far as I understand help in all cases.
R=jkummerow@chromium.org
Bug: v8:14549
Change-Id: I9608776065f30f7f98040f418235e1ca60f8deae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5383508
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92938}
commit 6fc3eab3c572770325e0617c1dc24173c20ab048
Author: Andreas Haas <ahaas@chromium.org>
Date: Tue Mar 19 10:37:10 2024 +0100
[profiler] Avoid data race in test by increasing sampling interval
There seems to be a data race in the CPU profiler when two samples get
collected at the same time. This happens in tests where samples get
collected explicitly through a test API, in addition to the samples that
get collected periodically by the profiler.
With this CL we increase the sampling interval of the profiler, so that
the test finishes before the profiler wants to collect its sample.
R=cbruni@chromium.org
Bug: v8:14549
Change-Id: Ie7678961e6b10a5250b2460b79a046f9c6b864ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5377871
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92887}
commit f9c2749c41b4c2a7dbbba8849933f2cc0bad32f9
Author: Andreas Haas <ahaas@chromium.org>
Date: Tue Feb 20 14:39:02 2024 +0100
[wasm] Fix data race in EstimateCurrentMemoryConsumption
The TypeFeedbackStorage was accessed concurrently by compilation on a
background thread and the GC on the main thread in
EstimateCurrentMemoryConsumption. This CL moves the access in
EstimateCurrentMemoryConsumption behind a lock.
R=mliedtke@chromium.org
Bug: v8:14631
Change-Id: I309614433824eaa2429e99f4aa8d6d532933ecc3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5309914
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92428}
commit 4b41b926e7292d75a1101ac5bc49c605ae1a8da3
Author: Clemens Backes <clemensb@chromium.org>
Date: Mon Feb 5 14:37:10 2024 +0100
[wasm] Fix data race when growing WasmDispatchTable
Use acquire load from the GC thread and release store from the main
thread when growing a table in-place.
R=omerkatz@chromium.org
Bug: v8:14608
Change-Id: I252bef13772c2db4c23545432b632859f56009ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5268604
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92199}
commit 769d7ab5ced2d3a1a7c04db169dda2468d326012
Author: Marja Hölttä <marja@chromium.org>
Date: Tue Jan 30 16:16:17 2024 +0100
[isolate] Fix a data race with the allow_compile_hints_magic_ cache
Background inline streaming threads might read the value before its
available, and race with setting the value.
We can't delay background inline streaming until the value is surely
available, so, handle the data race gracefully.
Bug: chromium:1519976
Change-Id: I6e8ebce47ad3918dad12ba11f7b0c318d32b5a7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5250112
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92116}
commit c68d7fb0e8e6eef55d2f9a56571c282fe1c991b3
Author: Clemens Backes <clemensb@chromium.org>
Date: Fri Jan 12 12:02:01 2024 +0100
[gc] Fix two more data races around EstimateCurrentMemoryConsumption
One in the type canonicalizer, one in the compilation state.
R=jkummerow@chromium.org
Bug: chromium:1517559
Change-Id: If39bce3fdc178785ee1ae7d67f5bbe89b55ae8fa
Fixed: v8:14557
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5190456
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91815}
commit 61c254f0dc3ed12f45c219e585eceb910edf4775
Author: Dominik Inführ <dinfuehr@chromium.org>
Date: Thu Dec 7 10:07:45 2023 +0100
[heap] NotifyPossibleGarbage() needs to run on main thread
This method always needs to run on the isolate's main thread because
MemoryReducer is not thread-safe. The data race was introduced
when background threads also started to invoke
StartIncrementalMarkingIfAllocationLimitIsReached().
Bug: chromium:1503063, chromium:1480975
Change-Id: I4c474adbd0f7b7ce0ef731555434b386a848049d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5097207
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91401}
commit 3bb28f80bff6dc31e8f44939264f701798d0fc21
Author: Dominik Inführ <dinfuehr@chromium.org>
Date: Mon Nov 27 09:34:42 2023 +0100
Reland "[heap] Switch to MainAllocator for shared space promotion"
This is a reland of commit 75f956b6f3121d8870b96b515ce85e8f8c5e28b0
This version of the CL fixes a data race caused by adding a page
without synchronization. This branch was only supposed to be run
by compaction spaces. The fix here is to simply use
is_compaction_space() again.
Original change's description:
> [heap] Switch to MainAllocator for shared space promotion
>
> This CL switches the last use case of ConcurrentAllocator to
> MainAllocator. The tricky thing about this particular use case is
> that while the MainAllocator instance is used for GC, we are
> actually not collecting this particular space in the case of
> worker isolates and shared space.
>
> This CL solves this by introducing a new method in_gc_for_space()
> that only returns true if this LAB is used for GC and the space
> is currently collected as well. Some use cases of in_gc() had to be
> switched to in_gc_for_space() for correctness.
>
> Alternatively one could argue that the allocator shouldn't even be
> considered to be in a GC. However, we likely don't want shared GCs
> to interrupt local GCs. So we would anyways need some kind of GC flag
> for those allocators to prevent that from happening. There are
> other smaller issues as well like that we don't have LocalHeaps for
> GC threads that make this harder as well.
>
> Bug: chromium:1480975
> Change-Id: I7c707402e928e95cb092c4c183ee69cbae285f9d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5057489
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#91171}
Bug: chromium:1480975
Change-Id: I8d9bf85875406668cd7a1e4df10cd346df85b0e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5060292
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91177}
commit 3f3e27d51ebca155b92cea0977a078831dc07b0a
Author: Dominik Inführ <dinfuehr@chromium.org>
Date: Mon Nov 27 07:37:09 2023 +0000
Revert "[heap] Switch to MainAllocator for shared space promotion"
This reverts commit 75f956b6f3121d8870b96b515ce85e8f8c5e28b0.
Reason for revert: Seems to cause data races.
Original change's description:
> [heap] Switch to MainAllocator for shared space promotion
>
> This CL switches the last use case of ConcurrentAllocator to
> MainAllocator. The tricky thing about this particular use case is
> that while the MainAllocator instance is used for GC, we are
> actually not collecting this particular space in the case of
> worker isolates and shared space.
>
> This CL solves this by introducing a new method in_gc_for_space()
> that only returns true if this LAB is used for GC and the space
> is currently collected as well. Some use cases of in_gc() had to be
> switched to in_gc_for_space() for correctness.
>
> Alternatively one could argue that the allocator shouldn't even be
> considered to be in a GC. However, we likely don't want shared GCs
> to interrupt local GCs. So we would anyways need some kind of GC flag
> for those allocators to prevent that from happening. There are
> other smaller issues as well like that we don't have LocalHeaps for
> GC threads that make this harder as well.
>
> Bug: chromium:1480975
> Change-Id: I7c707402e928e95cb092c4c183ee69cbae285f9d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5057489
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#91171}
Bug: chromium:1480975
Change-Id: Ib30d9637f374ba833d1c4d928e5140cdcb451976
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5061229
Auto-Submit: Dominik Inführ <dinfuehr@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/main@{#91173}
commit bb9b37d196a7ef2ca0f9175e1e99794167a3d09e
Author: Dominik Inführ <dinfuehr@chromium.org>
Date: Thu Nov 23 14:36:54 2023 +0100
[heap] Fix data race on Heap::global_allocation_limit_
This field can be updated outside a safepoint because of
Heap::NotifyContextDisposed(). However, at that point it might
also be read concurrently from a background thread (to check
whether incremental marking should be started).
This CL turns this field into an atomic to fix the race.
Bug: chromium:1480975
Change-Id: I06cbfc2bd5764ce88718e0d701d066c5ef5502f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5057293
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91143}
commit d15ef845947ba4ba5276038a1b1a5baa50759154
Author: Clemens Backes <clemensb@chromium.org>
Date: Mon Sep 4 17:43:44 2023 +0200
[wasm] Log lazily compiled code in all isolates
We were missing to log lazily compiled code in other isolates that use
the same {NativeModule}. Instead we only checked the isolate in which
lazy compilation was triggered.
This CL fixes that by calling {WasmEngine::LogCode} from {CompileLazy},
which properly checks all isolates that use a {NativeModule}.
As that method is pretty expensive (it takes a Mutex to protect against
data races), we add a cheap-to-access atomic boolean to the
{NativeModule}. The {WasmEngine} updates this whenever a new isolate
uses a module, an isolate dies, or logging is enabled in an isolate.
This should mitigate any performance regressions.
R=thibaudm@chromium.org
Bug: chromium:1407619
Change-Id: Id21ed59ed14c6fa25c9d664c53989bb5aae09114
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4790962
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89778}
commit 4564a561cb2df158b3e237f965205164a8e3ffd3
Author: Dominik Inführ <dinfuehr@chromium.org>
Date: Tue Aug 29 08:46:01 2023 +0000
Revert "Reland "[heap] Introduce Heap::MakeNewSpaceIterable method""
This reverts commit 2a76240fed2f6b0fb7e5d9bffc33da429333ef6f.
Reason for revert: Causes data races
Original change's description:
> Reland "[heap] Introduce Heap::MakeNewSpaceIterable method"
>
> This is a reland of commit bde589f3a6fd7bba05cd2bd1381e7c8f262239a5
>
> This CL contains the following changes compared to the first version
> of this CL:
> * Use EnsureYoungSweepingCompleted() to finish minor sweeping.
> * Avoids the PagedSpaceObjectIterator with minor ms since this
> class was using Heap::MakeHeapIterable() internally as well.
>
> Original change's description:
> > [heap] Introduce Heap::MakeNewSpaceIterable method
> >
> > Add method to make the new space iterable. This is useful for a
> > shared GC which needs the new space to be iterable.
> >
> > So far we simply used Heap::MakeHeapIterable for convenience for this purpose. However, this method makes the whole heap iterable which is
> > not really necessary. But more importantly, Heap::MakeHeapIterable performs a lot of actions and e.g. creates handles in
> > GCTracer::StopCycle. Client isolates are parked during a shared GC and therefore shouldn't create handles.
> >
> > Bug: chromium:1472372
> > Change-Id: Ia15ad5153e60e90c4732338a834a099e271caeec
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4813236
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#89632}
>
> Bug: chromium:1472372
> Change-Id: I084bf282236c28063c5ff1796ff3525854897f2c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4816530
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#89663}
Bug: chromium:1472372
Change-Id: I34427f9353b50bb483f731ebafb2e68b4cb67c63
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4821532
Auto-Submit: Dominik Inführ <dinfuehr@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/main@{#89670}
commit b71a94aa1891db7333dbd3b48d6b03ab6c980295
Author: Thibaud Michaud <thibaudm@chromium.org>
Date: Fri Jul 28 11:09:34 2023 +0200
Reland^3 "[wasm] Do not inline export wrappers for JSPI"
This is a reland of commit 9b7d2a9cd9bbcec35d5008a43056bfd1e1914a81
Also make the write to the Code::builtin_id field atomic to fix
the last tsan failure.
Original change's description:
> Reland "Reland "[wasm] Do not inline export wrappers for JSPI""
>
> This is a reland of commit 9ee1ba176a52b9ba6f8a773f7b0a5f1d9c77e4af
> Change: also load the builtin ID of the wrapper code object with
> an atomic relaxed load to avoid another data race. (Note: the failure
> that caused the revert is actually not caused by this CL. This is an
> unrelated fix for v8:14220).
>
> Original change's description:
> > Reland "[wasm] Do not inline export wrappers for JSPI"
> >
> > This is a reland of commit f43a566ce60a5e22be10ed77ebea807dcdd82a18
> >
> > The issue was a data race between a background compilation thread
> > reading the wrapper_code field to check if we can inline it, and the
> > generic wrapper tier-up trying to update the wrapper_code.
> >
> > It does not matter whether we read the value before or after the
> > tier-up, so just get the field with a relaxed load.
> >
> > Original change's description:
> > > [wasm] Do not inline export wrappers for JSPI
> > >
> > > To preserve the "JSPI behavior" of the exported function, do not inline
> > > the optimized js-to-wasm wrapper at the call site. Keep using the
> > > special WasmReturnPromiseOnSuspend builtin.
> > >
> > > R=ahaas@chromium.org
> > >
> > > Bug: v8:12191,v8:14200
> > > Change-Id: I93a8b0293c0c96541c336a90317cee03410dcfd6
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4711685
> > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > > Cr-Commit-Position: refs/heads/main@{#89151}
> >
> > Bug: v8:12191,v8:14200
> > Change-Id: I30459d98dd9f1942780cba344dee118011fa98bd
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4714608
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#89195}
>
> Bug: v8:12191,v8:14200,v8:14220
> Change-Id: Ifed60ad4b246ab8190fc511bc3b2bf182004c43a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4720865
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#89230}
Bug: v8:12191,v8:14200,v8:14220,v8:14227
Change-Id: I28468f35c6e91d966a030bc40eab25d254c8e516
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4727683
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89286}
commit fc299ac2bca17abeb4a185aedd57dc82d4558bf5
Author: Shu-yu Guo <syg@chromium.org>
Date: Thu Jul 27 17:20:00 2023 +0000
Revert "Reland "Reland "[wasm] Do not inline export wrappers for JSPI"""
This reverts commit 9b7d2a9cd9bbcec35d5008a43056bfd1e1914a81.
Reason for revert: More races sorry
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/16136/overview
Original change's description:
> Reland "Reland "[wasm] Do not inline export wrappers for JSPI""
>
> This is a reland of commit 9ee1ba176a52b9ba6f8a773f7b0a5f1d9c77e4af
> Change: also load the builtin ID of the wrapper code object with
> an atomic relaxed load to avoid another data race. (Note: the failure
> that caused the revert is actually not caused by this CL. This is an
> unrelated fix for v8:14220).
>
> Original change's description:
> > Reland "[wasm] Do not inline export wrappers for JSPI"
> >
> > This is a reland of commit f43a566ce60a5e22be10ed77ebea807dcdd82a18
> >
> > The issue was a data race between a background compilation thread
> > reading the wrapper_code field to check if we can inline it, and the
> > generic wrapper tier-up trying to update the wrapper_code.
> >
> > It does not matter whether we read the value before or after the
> > tier-up, so just get the field with a relaxed load.
> >
> > Original change's description:
> > > [wasm] Do not inline export wrappers for JSPI
> > >
> > > To preserve the "JSPI behavior" of the exported function, do not inline
> > > the optimized js-to-wasm wrapper at the call site. Keep using the
> > > special WasmReturnPromiseOnSuspend builtin.
> > >
> > > R=ahaas@chromium.org
> > >
> > > Bug: v8:12191,v8:14200
> > > Change-Id: I93a8b0293c0c96541c336a90317cee03410dcfd6
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4711685
> > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > > Cr-Commit-Position: refs/heads/main@{#89151}
> >
> > Bug: v8:12191,v8:14200
> > Change-Id: I30459d98dd9f1942780cba344dee118011fa98bd
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4714608
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#89195}
>
> Bug: v8:12191,v8:14200,v8:14220
> Change-Id: Ifed60ad4b246ab8190fc511bc3b2bf182004c43a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4720865
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#89230}
Bug: v8:12191,v8:14200,v8:14220
Change-Id: I7f67c0aaa2bba76ec1117a2d434dc7adc7f32fac
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4726482
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89236}
commit 9b7d2a9cd9bbcec35d5008a43056bfd1e1914a81
Author: Thibaud Michaud <thibaudm@chromium.org>
Date: Wed Jul 26 17:28:25 2023 +0200
Reland "Reland "[wasm] Do not inline export wrappers for JSPI""
This is a reland of commit 9ee1ba176a52b9ba6f8a773f7b0a5f1d9c77e4af
Change: also load the builtin ID of the wrapper code object with
an atomic relaxed load to avoid another data race. (Note: the failure
that caused the revert is actually not caused by this CL. This is an
unrelated fix for v8:14220).
Original change's description:
> Reland "[wasm] Do not inline export wrappers for JSPI"
>
> This is a reland of commit f43a566ce60a5e22be10ed77ebea807dcdd82a18
>
> The issue was a data race between a background compilation thread
> reading the wrapper_code field to check if we can inline it, and the
> generic wrapper tier-up trying to update the wrapper_code.
>
> It does not matter whether we read the value before or after the
> tier-up, so just get the field with a relaxed load.
>
> Original change's description:
> > [wasm] Do not inline export wrappers for JSPI
> >
> > To preserve the "JSPI behavior" of the exported function, do not inline
> > the optimized js-to-wasm wrapper at the call site. Keep using the
> > special WasmReturnPromiseOnSuspend builtin.
> >
> > R=ahaas@chromium.org
> >
> > Bug: v8:12191,v8:14200
> > Change-Id: I93a8b0293c0c96541c336a90317cee03410dcfd6
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4711685
> > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#89151}
>
> Bug: v8:12191,v8:14200
> Change-Id: I30459d98dd9f1942780cba344dee118011fa98bd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4714608
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#89195}
Bug: v8:12191,v8:14200,v8:14220
Change-Id: Ifed60ad4b246ab8190fc511bc3b2bf182004c43a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4720865
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89230}
commit 35eaaaf41d1e18c91ea36574e96236cd4c1cd30e
Author: Nikolaos Papaspyrou <nikolaos@chromium.org>
Date: Wed Jul 26 14:49:55 2023 +0200
[heap] Remove DCHECK from MemoryAllocator::IsOutsideAllocatedSpace
The DCHECK in MemoryAllocator::IsOutsideAllocatedSpace that was
introduced in https://crrev.com/c/4719165 is causing a data race
between concurrent marking and page allocation. This CL removes it.
It will be added again to the call site of this method in the CSS
visitor, in a subsequent CL.
Change-Id: Ia66596d095d61bccf1c6abcab1260c394d5304a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4720547
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89212}
commit 9776f53d8303f474632046ab373b0085aaa913d6
Author: Leszek Swirski <leszeks@chromium.org>
Date: Wed Jul 26 09:46:59 2023 +0000
Revert "Reland "[wasm] Do not inline export wrappers for JSPI""
This reverts commit 9ee1ba176a52b9ba6f8a773f7b0a5f1d9c77e4af.
Reason for revert: GC Stress: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/29112/overview
Original change's description:
> Reland "[wasm] Do not inline export wrappers for JSPI"
>
> This is a reland of commit f43a566ce60a5e22be10ed77ebea807dcdd82a18
>
> The issue was a data race between a background compilation thread
> reading the wrapper_code field to check if we can inline it, and the
> generic wrapper tier-up trying to update the wrapper_code.
>
> It does not matter whether we read the value before or after the
> tier-up, so just get the field with a relaxed load.
>
> Original change's description:
> > [wasm] Do not inline export wrappers for JSPI
> >
> > To preserve the "JSPI behavior" of the exported function, do not inline
> > the optimized js-to-wasm wrapper at the call site. Keep using the
> > special WasmReturnPromiseOnSuspend builtin.
> >
> > R=ahaas@chromium.org
> >
> > Bug: v8:12191,v8:14200
> > Change-Id: I93a8b0293c0c96541c336a90317cee03410dcfd6
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4711685
> > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#89151}
>
> Bug: v8:12191,v8:14200
> Change-Id: I30459d98dd9f1942780cba344dee118011fa98bd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4714608
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#89195}
Bug: v8:12191,v8:14200
Change-Id: I30c3323375e9c990615ea680e165ee5857dd876f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4717492
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89197}
commit 9ee1ba176a52b9ba6f8a773f7b0a5f1d9c77e4af
Author: Thibaud Michaud <thibaudm@chromium.org>
Date: Tue Jul 25 14:02:33 2023 +0200
Reland "[wasm] Do not inline export wrappers for JSPI"
This is a reland of commit f43a566ce60a5e22be10ed77ebea807dcdd82a18
The issue was a data race between a background compilation thread
reading the wrapper_code field to check if we can inline it, and the
generic wrapper tier-up trying to update the wrapper_code.
It does not matter whether we read the value before or after the
tier-up, so just get the field with a relaxed load.
Original change's description:
> [wasm] Do not inline export wrappers for JSPI
>
> To preserve the "JSPI behavior" of the exported function, do not inline
> the optimized js-to-wasm wrapper at the call site. Keep using the
> special WasmReturnPromiseOnSuspend builtin.
>
> R=ahaas@chromium.org
>
> Bug: v8:12191,v8:14200
> Change-Id: I93a8b0293c0c96541c336a90317cee03410dcfd6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4711685
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#89151}
Bug: v8:12191,v8:14200
Change-Id: I30459d98dd9f1942780cba344dee118011fa98bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4714608
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89195}
commit c53a7dff012c1869fb7e410bb7250c3901c276bb
Author: Omer Katz <omerkatz@chromium.org>
Date: Mon Jul 10 23:06:49 2023 +0200
[heap] Fix bug in untyped shared remembered set handling
crrev.com/c/4675298 fixed a data race in
CheckOldToNewSlotForSharedUntyped but accidentally also passed a slot
offset instead of a slot address when inserting to the OLD_TO_SHARED
remembered set.
This CL resotres the previous behavior.
Bug: v8:13012
Change-Id: I0bdebd196a5b515ab2929a0ae87359f071b8390b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4670262
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#88803}
commit 35b8bd30a6f3fe7f95d6783aa017067401e0290c
Author: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com>
Date: Mon May 8 16:23:20 2023 -0700
Check for background deserialization in CollectSourcePositionsForAllBytecodeArrays
There is a data race caused by the CPUProfiler trying to access the
DebugInfo of a SharedFunctionInfo that is being deserialized in another
thread.
This CL adds a mitigation by checking if the `script_or_debug_info` of
the SFI is set to `unititalized_deserialization_value`.
Bug: v8:13225
Change-Id: Ife3143183686b5a9fd7390d9ea65cbde2754a3ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4513482
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87762}
commit f8b9421f0da1382227728cb220b18cf44e9c60c4
Author: Omer Katz <omerkatz@chromium.org>
Date: Tue Mar 14 15:48:25 2023 +0100
[heap] Fix race in ephemeron remembered set
MinorMC doesn't currently use the dedicated ephemeron remembered set.
However, there was one path in full GC that was accidentally still using
it (only when evacuation had to be aborted).
As a result the ephemeron key could be found in both the OLD_TO_NEW
remembered set and the dedicated ephemeron remembered set. This leads to
a data race during evacuation when 2 threads are both trying to update
the key.
Drive-by: drop unused MarkCompactCollector::RecordLiveSlotsOnPage.
Bug: v8:13818
Change-Id: I1ba180ef949b7db2ff2abe4f1096f94cf7c93d2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4338012
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#86420}
commit 58debc3b8ffd4a61790e7e50576296c11f3c7fc1
Author: Omer Katz <omerkatz@chromium.org>
Date: Tue Mar 14 13:48:38 2023 +0100
[heap] Fix tsan race in sweeper
Making read/writes to promoted_page_iteration_in_progress_ relaxed means
tsan doesn't see them in terms of synchronization, causing it report
data races in subsequent code.
Bug: v8:13817
Change-Id: Ie0f74295e31e29feab3b010b6fc974346ccd3f4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4337916
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#86411}
commit dc7926bebd49d8749074c414dcf08a846bae0007
Author: Manos Koukoutos <manoskouk@chromium.org>
Date: Tue Feb 21 13:58:39 2023 +0100
Reland "[wasm] Do not store element segment entries in WasmModule"
This is a reland of commit 480a491e79337163be10655ce243587b14bcefb2
Change compared to original:
Reimplement constant expression decoding and generation of a
{Handle<Object>} in module-instantiate.cc. We fix two issues this way:
- We fix a data race that was caused by module instantiation setting
the {declared} field of functions in a {WasmModule}.
- We remove a redundant decoding pass of the constant expression.
Original change's description:
> [wasm] Do not store element segment entries in WasmModule
>
> Instead, decode them from the wire bytes as needed. This is to save
> some space, in anticipation of storing computed element segments in the instance object (for wasm-gc, see linked CL).
> Drive-by: this breaks some cctests, so we move them to mjsunit.
>
> Bug: v8:7748
> Change-Id: I71019f5624a33dd18f07b05107555a3fac788a8c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4255645
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85912}
Bug: v8:7748
Change-Id: I58dcf6cdb5e71cae983e613cb17b665479fc5c63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4269410
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85956}
commit 23e7e5ff07a283df93eb707c0676d14e3a290151
Author: Tobias Tebbi <tebbi@chromium.org>
Date: Fri Feb 17 10:14:37 2023 +0100
[compiler] fix concurrent compilation race on accessing JSFunction::code
The race that we fix here has basically the following structure:
Main thread:
1. Create and initialize Code object and InstructionStream objects.
2. Store-release Code object to JSFunction::code
3. Copy JSFunction::code from one JSFunction to another one.
Background compile thread:
1. Load-acquire JSFunction::code from the second JSFunction.
2. Access the Code object and then the InstructionStream object.
Tsan classified this as a data race, probably also because it could
not see step (3.) on the main thread, as it is in generated code.
This could be fixed by adding a release-barrier after initialization
or by using release-stores whenever copying the `Code` pointer.
However, it is simpler to fix it by using `TryMakeRef()`, which
ensures that the `Code` object was either fully initialized before
concurrent compilation started or we won't access it at all.
Drive-by cleanup: Remove incomplete release-store semantic when writing
`JSFunction::code`, which was added in https://chromium-review.googlesource.com/c/v8/v8/+/2676633
Bug: v8:13705
Change-Id: Ia38ecf78003641c315c10f560801c368906c937e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4241157
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85878}
commit 29d54b0408cf072d42c1018367555552aea7ce5c
Author: Omer Katz <omerkatz@chromium.org>
Date: Mon Jan 23 10:39:45 2023 +0100
Fix data race when writing to Profiler::overflow_
This CL resolves the races in
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8791194392783872945/+/u/Check/LogAllTest.LogAll
Bug: v8:13665
Change-Id: Ic40fe995eb9a335cdb0477106009a4d455273cb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4187215
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85438}
commit 54d255ab23bfc00308bebbd2a720946a50186b63
Author: Omer Katz <omerkatz@chromium.org>
Date: Thu Jan 19 19:41:37 2023 +0100
[heap] Fix race in MarkingBarrier
The data race in [1] occurs because when reaching marking-barrier-inl.h,
value is in the shared heap while host is in the client heap.
Generally concurrent sweeping and marking barriers should not be active
at the same time. However, that only holds for a single heap.
In this case, the client is in the midst of incremental marking, thus
marking barriers are active for it, while concurrent sweeping is active
on the shared heap/space. This results in a race between reading the
value's mark bit and clearing the mark bit for the chunk.
[1] https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8791534956079065361/+/u/Check__flakes_/regress-crbug-1394741
Bug: v8:13665
Change-Id: I1b6210b9162b78b3c3635802a1e74432f5c89757
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4181038
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85412}
commit 562b65a86e6ce0cb417577a6296c5a7958d8162b
Author: Omer Katz <omerkatz@chromium.org>
Date: Thu Jan 19 11:56:04 2023 +0100
[heap] Fix data races in debug builds
These fixes address race observed in
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8792972887942555249/+/u/Benchmarks__flakes_/splay
and
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8792972887942555249/+/u/Check_-_extra/regress-1146013
Bug: v8:13665
Change-Id: Ief02d57907dd1930fc5c719503fd98e42171991b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4171638
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85393}
commit 713cf5dfa728b21c48f711fa63379c2741c6367d
Author: Omer Katz <omerkatz@chromium.org>
Date: Fri Jan 13 15:08:10 2023 +0100
[heap] Fix data races with concurrent promoted page iteration
V8 uses memcpy and memmove for implementing Heap::CopyRange and
Heap::MoveRange respectively, but only when concurrent marking is off.
When concurrent marking is on, atomic stores are used to avoid data
races.
Since iteration of promoted pages also iterates objects concurrently,
memcpy and memmove should be avoided while it is active as well.
A dedicated bailout for promoted page iteration is added rather than
checking when sweeping is active. Sweeping will likely be active
until the next GC, which means relying on it here would prevent us
from ever using memcpy and memmove.
Bug: chromium:1407041
Change-Id: Idde80b456df843f91ef7ef05c0694c5930711ae4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4165084
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85318}
commit f0254afaab04039d7430f8e6c18671144dd65643
Author: Samuel Groß <saelo@chromium.org>
Date: Wed Jan 4 13:13:12 2023 +0100
[sandbox] Initialize EPT evacuation entries atomically
Currently, evacuation entries are initialized non-atomically as they
will only be accessed during sweeping. However, it can happen that
another thread attempts (but fails) to allocate the same table entry,
causing a memory read from the same entry. If that happens, TSan will
complain about a data race. Using an atomic store avoids this.
Bug: chromium:1370743
Change-Id: Idaa5548494d4b1660ee5a798966dd09bf4b3d55c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135880
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85091}
commit 825915a75cf75793394d7eea77d9d74a919bc8e0
Author: Omer Katz <omerkatz@chromium.org>
Date: Wed Dec 7 23:40:28 2022 +0100
[heap] Replace ZapCode in Sweeper with an atomic variant
Resolve a data race between concurrent sweeping and writing fillers by
the main thread.