PSA: Enabling Oilpan GC per thread heap for Compositor Worker

[Keishi Hattori]

Hi blink-dev

I will be flipping the flag to turn on Oilpan GC per thread heap on the Compositor Worker. CL

When per thread heap is enabled, references to objects in other threads need to use CrossThreadPersistent, instead of Member/Persistent. If you forget you will hit an assert.

Oilpan GC per thread heap splits the previously monolithic Oilpan heap for each thread, enabling GC to run separately for each thread. Details can be found in the design doc: https://docs.google.com/document/d/14MzxMuUV9e5ZgxbZL3-jCMKa3S-UJGsbYSmRodLh9uc/edit#

If you have any questions, or notice anything odd, please let me know.

Thanks.

Keishi

[Elliott Sprehn]

This is super exciting! Once this lands we can remove safe points?

[Kentaro Hara]

This is super exciting! Once this lands we can remove safe points?

Yes.

Also once we have succeeded at enabling the per-thread heap on compositor workers, we're planning to enable it on all workers.

--

Kentaro Hara, Tokyo, Japan

[Rick Byers]

On Wed, Sep 14, 2016 at 11:32 PM, Kentaro Hara <har...@chromium.org> wrote:

This is super exciting! Once this lands we can remove safe points?

Yes.

Also once we have succeeded at enabling the per-thread heap on compositor workers, we're planning to enable it on all workers.

Great, thank you for pushing through on this!  Although I'm personally excited about CW it's the larger principle of performance isolation of workers I was most concerned with here (since that's really the whole point of any worker).

[Kentaro Hara]

Just a quick update:

keishi@ has finished shipping Oilpan's per-thread heap on all threads in Blink and it has been stabilized on ToT.

Benefits:

- Now GC performance is completely isolated per thread. Worker threads don't need to stop when the main thread allocates a lot of objects and triggers a GC.

- The per-thread heap massively simplified Oilpan's infrastructure. For example, we don't need to stop all threads when some thread wants to trigger a GC. Also Oilpan had a very complicated state transition model because it was possible that a thread gets involved in the next GC (triggered by another thread) before the thread finishes weak processing, eager sweeping etc of the previous GC. All the subtle logic is gone. I hope this will fix various undeterministic crash reports the Oilpan team couldn't reproduce locally.

[Rick Byers]

Wow, that's excellent news - thank you!

Were there any downsides?  Personally I often feel the message passing model of multi-threading is strictly superior to shared-memory multi-threading, but intellectually I know it's a trade off where shared memory and locking sometimes is the better choice.  So I'd be interested to know what we lost in order to gain the simplicity and more predictable performance properties  ;-)

[Keishi Hattori]

Basically we got those benefits in exchange for increased usage of CrossThreadPersistent.

Sharing objects across threads is still possible so I haven't had to make performance regressing changes. However using the message passing model is encouraged since it will limit cross thread references and reduce confusion about whether to use a CrossThreadPersistent or a Member/Persistent.

--

- Keishi