FYI: Shared memory programming policy in Blink

[Koji Ishii]

The subject is under discussion in platform-arc...@chromium.org, in case you're interested in.

The draft is in line with what we learned from the parallel shaping prototype. It's a bit challenging when we want to parallelize tasks in a lifecycle phase under this model, because we don't go back to the event loop until the phase ends. I hope we can find a good solution for this in the near future.

[Kentaro Hara]

The guideline is not finalized yet. I welcome your feedback :)

On Mon, Sep 26, 2022 at 5:12 PM Koji Ishii <ko...@chromium.org> wrote:

The subject is under discussion in platform-arc...@chromium.org, in case you're interested in.

The draft is in line with what we learned from the parallel shaping prototype. It's a bit challenging when we want to parallelize tasks in a lifecycle phase under this model, because we don't go back to the event loop until the phase ends. I hope we can find a good solution for this in the near future.

--

Kentaro Hara, Tokyo

[Philip Rogers]

Are the past issues with shared memory limited to code interacting with javascript/dom/oilpan?

We used shared memory at the end of the main-thread pipeline, at the main thread -> compositor thread boundary. This code lives in cc/ and szager@ is currently experimenting with bringing that knowledge a little deeper into blink. The design issues closer to the end of the pipeline are quite a bit different than those closer to the DOM, and I am wondering if the guidance can reflect that.

--
You received this message because you are subscribed to the Google Groups "rendering-core-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rendering-core-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/rendering-core-dev/CABg10jzU2FuRDf3M6r9fC6%2BxOyW%2BARTz2y1R2kPRTG-Y44ZxxA%40mail.gmail.com.

[Stefan Zager]

FWIW, I think the draft guidance is fine, with the caveat that there is room for well-chosen exceptions.

Phil mentioned the main/compositor thread boundary, which has *always* done a certain amount of shared concurrent access to non-gc data.

Additionally, the blink main thread scheduler is entirely based on extensive use of atomics, for what I think are good reasons.

So again, the general guidance to favor message passing is sound, but there are existing exceptions, and there are legit reasons to do something different. Maybe the draft guidance should indicate that exceptions can be granted on a case-by-case basis, but must be carefully planned and reviewed.

[Kentaro Hara]

Are the past issues with shared memory limited to code interacting with javascript/dom/oilpan?

Yes. As far as I know, the past issues were interacting with JavaScript, DOM and/or Oilpan.

So again, the general guidance to favor message passing is sound, but there are existing exceptions, and there are legit reasons to do something different. Maybe the draft guidance should indicate that exceptions can be granted on a case-by-case basis, but must be carefully planned and reviewed.

Exactly. The guidance is saying that the exception should be reviewed by platform-architecture-dev@ :) (Regarding the main thread -> compositor thread boundary parallelization, I'm still wondering why we cannot use generational PhisicalFragments with message passing but let's discuss separately :-)

--

Kentaro Hara, Tokyo