Hey everyone -
The new library offers a stable API surface
with code comments and examples in code (if we forgot something, please file a bug) that follows V8's general API stability process
Some other highlights:
- Uses IWYU (API and internally) to avoid pulling in large parts of the heap for e.g. just using a managed reference type;
- Unit tests
for each individual component in the C++ garbage collector;
- Test target and a garbage collection playground that builds within seconds;
- More correctness checks that already found issues in existing code;
- Better tooling around DevTools heap snapshot and more accurate accounting in tracing's MemoryInfra
The effort (tracking bug
) roughly took ~1.5 years and involved a lot of user code cleanup as well. Many fruitful discussions happened and quite some code was migrated and re-written. Thanks @Anton Bikineev
and @Omer Katz
for driving the implementation work.
A1: Neutral on competitive benchmarks; smaller ups and downs on micro benchmarks. We don't expect big changes as the overall architecture stays the same.
Q2: What does this mean for Blink developers? Anything I need to change in my code?
A2: We have stayed fully backwards compatible with the API. If we haven't touched your code while migrating, you don't need to change anything as of now. Going forward we may adjust the APis following V8's API stability process. We will keep maintaining the Blink GC API reference
, although we may move some more general docs closer to the library.
Q3: What's up with IWYU for Oilpan in Blink?
A3: So far we have kept the include-all headers around but we'd like to move to IWYU to avoid pulling in too many V8 headers everywhere.
Q4: Can we use Oilpan within V8 itself?
A4: Not just yet. Stay tuned on updates in this area.
Encountering issues, or have suggestions? Let us know:
- Monorail: Blink>GarbageCollection (Chromium), Oilpan (V8)