> *Can you relate the time spent more in concurrent marking vs the time saved on the main thread (incremental steps above)?*
I am not 100% sure about that but here is my understanding: When more workers are activated, the speed of each worker may decrease but the total speed will increase. Rough calculation: 508.91 KB/ms/worker *15 worker=7633.65 KB/ms 669.86 KB/ms/worker * 7 worker = 4689.02 KB/ms The concurrent marking task is scheduled when the incremental marking starts . For each steps of incremental marking, it need to mark "bytes_to_process" heapobjects. When the local worklists is empty, the incremental marking will complete and invoke major gc . That means, only when concurrent marking complete most marking works, can the main thread local worklist be empty, otherwise it can always steal a segment from global worklist. If the concurrent marking have more worker to mark heapobjects faster, the incremental marking can also complete earlier. This may explain why the occurrence and duration of V8.GC_MC_INCREMENTAL are decreased. And the execution will also benefit from that without write barrier introduced by incremental marking. > *What we can always do is exposing a flag though for users that don't care about this tradeoff.* I suggest to expose that a flag. I am not urgent with that, just share some findings and confusions with community. Thanks! Regards, Jianxiao On Thursday, June 23, 2022 at 11:10:12 PM UTC+8 Michael Lippautz wrote: > On Thu, Jun 23, 2022 at 10:06 AM Jianxiao Lu <[email protected]> wrote: > >> Test on an AWS server: >> Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz (16 cores) >> >> Running webtooling with d8 >> >> Here is the v8.gc tracing data: >> [image: baseline.png] >> >> [image: 15worker.png] >> Raw tracing log files: >> https://drive.google.com/drive/folders/1NRQCjNQ5x9RDHA0AVvTOr8neuARyheq-?usp=sharing >> >> >> For the concurrent marking speed, I simply sum up the KB and ms in the >> trace log and divide them (KB/ms), >> For each worker: >> baseline: 640.5, 669.86, 684.72 >> 15 workers:508.91, 515.51, 503.51 >> > > So that's 20-25% less efficient in terms of cycles. It's hard to say > whether the trade off in terms of absolute time is worth it. > > Can you relate the time spent more in concurrent marking vs the time saved > on the main thread (incremental steps above)? > > >> Maybe it's better to replace the fixed kMaxTasks with core number? Just >> like what parallel compaction do. >> >> https://source.chromium.org/chromium/chromium/src/+/main:v8/src/heap/mark-compact.cc;l=472;bpv=1;bpt=0?q=NumberOfParallelCompactionTasks&ss=chromium%2Fchromium%2Fsrc >> >> > Parallel compaction is more coarse grained and scales a little better I > think. > > I am curious whether you can provide the trade off (see above). What we > can always do is exposing a flag though for users that don't care about > this tradeoff. > > >> Regards, >> Jianxiao >> On Wednesday, June 22, 2022 at 2:03:30 AM UTC+8 Michael Lippautz wrote: >> >>> On Tue, Jun 21, 2022 at 11:36 AM Jianxiao Lu <[email protected]> wrote: >>> >>>> Thanks for the explanation. The second screenshot is 1520ms~1560ms in >>>> fact. The snapshots were taken from the first major gc running webtooling. >>>> Because I believe the first major gcs are relatively predictable and >>>> consistent. (Maybe I am wrong). >>>> >>>> I will check with your suggestion later. Does the gc-tracer already >>>> have something to record the mark-bytes/ms ? Or I need to try to implement >>>> one? >>>> >>> >>> --trace-concurrent-marking will log concurrently marked bytes and >>> timespans which can be used to compute the speed. Any custom logging will >>> also do though. >>> >>> -Michael >>> >>> >>>> >>>> Thanks, >>>> Jianxiao >>>> >>>> On Tuesday, June 21, 2022 at 3:08:10 PM UTC+8 [email protected] >>>> wrote: >>>> >>>>> On Tue, Jun 21, 2022 at 8:33 AM Jianxiao Lu <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> https://source.chromium.org/chromium/chromium/src/+/main:v8/src/heap/concurrent-marking.h;l=59?q=kMaxTasks&sq=&ss=chromium >>>>>> >>>>>> The code comments above seems out of date. So I wonder if this >>>>>> limitation is intentional or just no be updated in time. >>>>>> >>>>>> Here is a snapshot in webtooling (d8). >>>>>> >>>>>> [image: 7.png] >>>>>> >>>>>> After I tuned the worker number( >>>>>> https://chromium-review.googlesource.com/c/v8/v8/+/3711496): >>>>>> [image: 15.png] >>>>>> >>>>>> Seems that we can benefit from more worker? >>>>>> >>>>> >>>>> This really depends on what the average size of the heap is.The >>>>> numbers were chosen as a compromise between small and large heaps and >>>>> low-end vs desktop devices. Also, the algorithm doesn't scale linearly >>>>> but >>>>> there's smaller trade offs here and there which add up as the # tasks are >>>>> increased. >>>>> >>>>> Did the absolute time actually improve? I see 1280ms-1340ms in the >>>>> first screenshot vs 1520ms-1580ms. You could check marked bytes/s as a >>>>> proxy of whether the helper tasks are still efficient or not. >>>>> >>>>> -Michael >>>>> >>>>> >>>>>> -- >>>>>> -- >>>>>> v8-dev mailing list >>>>>> [email protected] >>>>>> http://groups.google.com/group/v8-dev >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "v8-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/v8-dev/2944463a-a964-40a9-91f4-fba7a74debe8n%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/v8-dev/2944463a-a964-40a9-91f4-fba7a74debe8n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> -- >>>> v8-dev mailing list >>>> [email protected] >>>> http://groups.google.com/group/v8-dev >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "v8-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/v8-dev/3e8a9fd6-0a7f-424a-843c-9d3be714ecebn%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/v8-dev/3e8a9fd6-0a7f-424a-843c-9d3be714ecebn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/50b7b577-3304-4227-ae7c-1b59f8d4690bn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/v8-dev/50b7b577-3304-4227-ae7c-1b59f8d4690bn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/814f0eb4-a805-4d90-9123-165889eac1ddn%40googlegroups.com.
