1877620 - Parallel GC appears to be not used in certain places (Part2)

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, task)

Description

[Mayank Bansal]

Profile1: https://share.firefox.dev/3HDYm2b
See this area: 25s-30s (https://share.firefox.dev/42nz8Pu)

Profile2: https://share.firefox.dev/48Z9Auj
See this area: 6.5s-8.5s (https://share.firefox.dev/3SF2tl9)

Profile3: https://share.firefox.dev/3Sn2h8A
Basically all the area doesnt appeat to use any parallel GC

To repro the profile, go to : https://codepen.io/hippiefuturist/pen/NRWOxM
no of branches = 8 , Recursion level = 7 OR no of branches = 7 , Recursion level = 9

Feel free to WONTFIX :)

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[Mayank Bansal]

Profile4: https://share.firefox.dev/3HIDvel

1. https://share.firefox.dev/42kPXKC (parallel gc used in only the first half of the 840ms GCSlice)
2. No parallel GC used in this range https://share.firefox.dev/49axbaY

Comment 3

[Mayank Bansal]

Last ditch GC's appear to use more than 2 threads: https://share.firefox.dev/49in8Rd

And in this profile, the parallel GC is done for unexpected parts :https://share.firefox.dev/3uceUvn (STR URL: https://rue-a.github.io/L-Systems/)

Comment 4

[Mayank Bansal]

No parallel GC in this part of a profile : https://share.firefox.dev/49jjdEj (https://nolandc.com/sandbox/fractals/?x=589&y=392&l=7&d=10&sa=60&a=60&s=F&r=A,-F+AA++A+F--F-A,F,F+A++A-F--FF-A+)

Comment 5

[Mayank Bansal]

No parallel GC in this 110ms part of the profile : https://share.firefox.dev/49evaLD
(STR is to open https://share.firefox.dev/3LIvWqm and select-and-drag some range in the profile for analysis)

Comment 6

[Jon Coppeard (:jonco)]

(In reply to Mayank Bansal from comment #3)
We now try to run marking in parallel which uses a maximum of two threads, but marking is not the only part of the GC.

Last ditch GC's appear to use more than 2 threads: https://share.firefox.dev/49in8Rd

This is doing compacting which can use more threads.

(In reply to Mayank Bansal from comment #4)
(In reply to Mayank Bansal from comment #5)

These profiles are finalizing which happens using a single helper thread while the main thread returns to the mutator.

You can usually which part of the GC is running by hovering over the profiler track to see the stack and looking at the method names to see whether they include 'marking', 'sweeping'/'finalizing', or 'updating' (compacting).

So most of these profiles look fine, with the exception of profile three in comment 0, where I would have expected to see parallel marking. It's probably due to the very specific data structure generated by the workload though.

Comment 7

[Mayank Bansal]

Cool! Looks like all the cases are expected.
Should I close this bug , and stop looking at this specific issue in future profiles?

Comment 8

[Mayank Bansal]

Closing this for now.