That is exactly what Chrome is not. It's not a monolithic process, with a large pool of green threads being scheduled to run on native threads using runtime trickery.
Instead it's just a bunch of shared-nothing exec-ed processes that are scheduled by the OS kernel, have their mallocs handled directly by the OS libc, and have their address space mapped and reclaimed by the OS kernel's VMM.
In my own work, when I fork threads that are run and executed by the kernel, I still make decisions outside the kernel about how those threads run. I may tell threads to go to sleep, wait for another thread to finish something, or prefer a certain thread to run over others.
Yes, they are still scheduled by the OS kernel, but they are also being controlled by my own scheduling algorithms. I call this scheduling, because it's the same problem as OS level scheduling. And if I have to do it, I imagine Chrome has to do it. In this scenario, if you want to understand the runtime behavior of the threads, you must consider both OS kernel level decisions and my scheduling decisions.
I would also be surprised if there was no Chrome memory management inbetween malloc and the OS kernel.
"Web content has evolved to contain significant amounts of active code that run within the browser, making many web sites more like applications than documents. This evolution has changed the role of the browser into an operating system rather than a simple document renderer. Unlike current browsers, Chromium is built like an operating system to run these applications in a safe and robust way, using multiple OS processes to isolate web sites from each other and from the browser itself."
That is exactly what Chrome is not. It's not a monolithic process, with a large pool of green threads being scheduled to run on native threads using runtime trickery.
Instead it's just a bunch of shared-nothing exec-ed processes that are scheduled by the OS kernel, have their mallocs handled directly by the OS libc, and have their address space mapped and reclaimed by the OS kernel's VMM.