V8 Garbage Collector
Orinoco, V8’s garbage collector, evolved from a sequential stop-the-world implementation into a mostly parallel and concurrent collector with incremental fallback.
Over the past years the V8 garbage collector (GC) has changed a lot. The Orinoco project has taken a sequential, stop-the-world garbage collector and transformed it into a mostly parallel and concurrent collector with incremental fallback. Note: If you prefer watching a presentation over reading articles, then enjoy the video below! If not, skip the video and read on. Any garbage collector has a few essential tasks that it has to do periodically: Identify live/dead objects Recycle/reuse the memory occupied by dead objects Compact/defragment memory (optional) These tasks can be performed in seq
Explore this link on the map →related reading
- Mechanical Sympathymechanical-sympathy.blogspot.com
- Working With SGen | Monomono-project.com
- Main - Shenandoah - OpenJDK Wikiwiki.openjdk.org
- Fundamentals of garbage collection - .NET | Microsoft Learnlearn.microsoft.com
- A Guide to the Go Garbage Collector - The Go Programming Languagego.dev
- NYSRGnotes.ekzhang.com
- Speed up GC by prefetching during marking by stedolan · Pull Request #10195 · ocaml/ocaml · GitHubgithub.com
- abseil / Performance Hintsabseil.io
- Speculation in JavaScriptCore | WebKitwebkit.org
- Memory Allocation in Go | Melatoninghiant3223.github.io
- PEP 703 – Making the Global Interpreter Lock Optional in CPython | peps.python.orgpeps.python.org
- Avoiding high GC overhead with large heaps | Gopher Academy Blogblog.gopheracademy.com