Skip to content

Investigate possibilities to prevent pause times due to synchronously blocking until concurrent marking is done #47492

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
mkustermann opened this issue Oct 18, 2021 · 0 comments
Closed

Investigate possibilities to prevent pause times due to synchronously blocking until concurrent marking is done #47492

mkustermann opened this issue Oct 18, 2021 · 0 comments
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. vm-gc Related to the VM's garbage collector

Comments

@mkustermann
Copy link
Member

Under some conditions (e.g. promotions) a thread will synchronously wait for concurrent marking to finish. This could block a thread for prolonged periods of time.

We should investigate possibilities to split this time up into smaller chunks, possibly by making fast-allocating-threads "take a small break" if they know the concurrent marker will have hard time catching up. Possibly by making such threads even help with marking.

Furthermore we see sometimes back-to-back new-space collection with finalization of concurrent mark (as well as parallel mark). We should think about possible ways to avoid this, because doing two such already long synchronous operations back-to-back can create even longer synchronous pauses.

I'll attach an example timeline trace that was created using a slightly modified version of https://gist.github.com/mit-mit/ffa606e17569cecbd2c47c234ac1be21#file-isolate2-perf-md

/cc @rmacnak-google has some ideas here.

timeline.json
@mkustermann mkustermann added area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. vm-gc Related to the VM's garbage collector labels Oct 18, 2021
@mkustermann mkustermann mentioned this issue Oct 20, 2021
Open
copybara-service bot pushed a commit that referenced this issue Jun 13, 2022
@rmacnak-google
[vm, gc] Remove the growth policy's hard limit when concurrent markin…
305c3e3 
…g is available.

Instead, impose back-pressure by making mutators assist with marking as they allocate.

Synchronous marking may still occur if the heap grows to --old_gen_heap_size or the OS is out of memory.

TEST=ci
Bug: #47492
Change-Id: I2538f9e9b6d67bbbca0951d5162075a950658380
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246180
Reviewed-by: Siva Annamalai <[email protected]>
Reviewed-by: Martin Kustermann <[email protected]>
Commit-Queue: Ryan Macnak <[email protected]>
copybara-service bot pushed a commit that referenced this issue Jun 22, 2022
@rmacnak-google
[vm, gc] Apply incremental marking back-pressure in proportion to int…
2e4107c 
…ernal allocation size.

In particular, do not apply incremental marking back-pressure for external allocations. External allocations do not cause additional marking work. If a mutator thread performs a storm of external allocations, this should not cause it to effectively become a marking thread.

TEST=ci
Bug: #47492
Bug: flutter/flutter#106305
Change-Id: Icace57e73d695143f7e295924b61b9b1c04be121
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249403
Commit-Queue: Ryan Macnak <[email protected]>
Reviewed-by: Martin Kustermann <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. vm-gc Related to the VM's garbage collector
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mkustermann @rmacnak-google