Some Questions about GC and DisplayCompositor

[THK]

Hello everyone,

I have some conceptual questions about Chromium. I would appreciate it if you help me.

1. Garbage Collection except V8 & Blink?

  I know that Blink has 'Oilpan' Garbage Collector and V8 has another GC mechanism.

  (Maybe they'll be integrated to 'Unified GC'.)

   But how about the Browser process, Renderer compositor thread and GPU, etc?

   Is there any GC mechanism for them?

  - Unified GC: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Intent$20to$20Implement$3A$20Unified$20V8$20$26$20Blink$20Garbage$20Collection$20(aka$20Unified$20Heap)%7Csort:date/blink-dev/tg2rXkjHw9g/jaxFpqUQBwAJ

  - V8 Orinoco GC project: https://v8.dev/blog/trash-talk

2. I know that the compositing(?) part of Browser process is being transferred to 'Viz' service.

      But It seems to be experimental feature. So the Question is

   - Which thread is the DisplayCompositor(which aggregates CompositorFrames) lives in now?
     I/O Thread of the Browser process?

Sincerely,

Taehyun

[dan...@chromium.org]

On Fri, Apr 5, 2019 at 12:46 PM Taehyun Kyong <th.k...@lge.com> wrote:

Hello everyone,

I have some conceptual questions about Chromium. I would appreciate it if you help me.

1. Garbage Collection except V8 & Blink?

  I know that Blink has 'Oilpan' Garbage Collector and V8 has another GC mechanism.

  (Maybe they'll be integrated to 'Unified GC'.)

  - Unified GC: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Intent$20to$20Implement$3A$20Unified$20V8$20$26$20Blink$20Garbage$20Collection$20(aka$20Unified$20Heap)%7Csort:date/blink-dev/tg2rXkjHw9g/jaxFpqUQBwAJ

  - V8 Orinoco GC project: https://v8.dev/blog/trash-talk

   But how about the Browser process, Renderer compositor thread and GPU, etc?

   Is there any GC mechanism for them?

Outside for blink/v8 renderer code we use explicit malloc/free. I don't know of any GC usage in the browser or gpu process, no.

 

2. I know that the compositing(?) part of Browser process is being transferred to 'Viz' service.

      But It seems to be experimental feature. So the Question is

   - Which thread is the DisplayCompositor(which aggregates CompositorFrames) lives in now?
     I/O Thread of the Browser process?

As the text in about:flags says, the display compositor is in the gpu process (on a compositor thread). It is not in the browser process.

This has been enabled on most platforms now, so I think experimental is not the correct qualifier at this point. :)

 

Sincerely,

Taehyun

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/172186e4-6c6a-e53e-1cf2-ed34ffa0b701%40lge.com.

[THK]

Thank you for your answer, danakj.

So can I think like below?

Threads of GPU Process

 - Compositor Thread (= Viz Service) aggregates the CompositorFrame & Browser UI,

   and generating GL calls through Command Buffer.

 - Main Thread: Where the actual GL call occurs

Sincerly,

Taehyun

2019년 4월 6일 토요일 오전 2시 0분 54초 UTC+9, danakj 님의 말:

[dan...@chromium.org]

Take a look at the OOPD design document off the chromium graphics page for all the details.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/559dba7f-1e1b-4c9c-8832-f065b6015eba%40chromium.org.