Is this just for the preload scanner? MQs use a fixed dialect, we should just convert it all to enum tokens (and ints) and use a simple parser so there's no strings.
On Sat, Jan 4, 2014 at 12:26 PM, Yoav Weiss <yo...@yoav.ws> wrote:
Following Adam Barth's response on the WHATWG list, I'd like to further understand the complexity of implementing off-the-main-thread MQ evaluation.Similar past concerns have led me to prototype off-the-main-thread MQ evaluation a few months back. As far as I can tell, the only thing preventing such evaluation is the thread-safety of the MediaQueryExp class, and specifically its use of AtomicStrings.Since I wrote the CL as a prototype, I've simply converted the class's AtomicString variables & members into String. I'm well aware that this is not ideal, and other ways to make it thread safe should be employed, but once this hurdle to thread safety is passed, everything else seemed to work.I'd like to know if I'm missing any other components that need to be thread-safe in order to evaluate MQs.Currently we cannot represent CSSValues off the main thread because they're RefCounted and we don't want to use thread-safe ref counting. After Oilpan lands, CSSValues will be GarabageCollected, which will let us interact with them off the main thread.
On Sat, Jan 4, 2014 at 2:56 PM, Adam Barth <aba...@chromium.org> wrote:
On Sat, Jan 4, 2014 at 12:26 PM, Yoav Weiss <yo...@yoav.ws> wrote:
Following Adam Barth's response on the WHATWG list, I'd like to further understand the complexity of implementing off-the-main-thread MQ evaluation.Similar past concerns have led me to prototype off-the-main-thread MQ evaluation a few months back. As far as I can tell, the only thing preventing such evaluation is the thread-safety of the MediaQueryExp class, and specifically its use of AtomicStrings.Since I wrote the CL as a prototype, I've simply converted the class's AtomicString variables & members into String. I'm well aware that this is not ideal, and other ways to make it thread safe should be employed, but once this hurdle to thread safety is passed, everything else seemed to work.I'd like to know if I'm missing any other components that need to be thread-safe in order to evaluate MQs.Currently we cannot represent CSSValues off the main thread because they're RefCounted and we don't want to use thread-safe ref counting. After Oilpan lands, CSSValues will be GarabageCollected, which will let us interact with them off the main thread.Are you sure about this? I thought one of the design ideas with Oilpan was to enable precise GC to run from the message loop, where we could assume that it is not necessary to conservatively scan call stacks. It seems that this would require special treatment if any objects are to be shared across threads.
On Sat, Jan 4, 2014 at 9:00 PM, Darin Fisher <da...@chromium.org> wrote:
On Sat, Jan 4, 2014 at 2:56 PM, Adam Barth <aba...@chromium.org> wrote:
On Sat, Jan 4, 2014 at 12:26 PM, Yoav Weiss <yo...@yoav.ws> wrote:
Following Adam Barth's response on the WHATWG list, I'd like to further understand the complexity of implementing off-the-main-thread MQ evaluation.Similar past concerns have led me to prototype off-the-main-thread MQ evaluation a few months back. As far as I can tell, the only thing preventing such evaluation is the thread-safety of the MediaQueryExp class, and specifically its use of AtomicStrings.Since I wrote the CL as a prototype, I've simply converted the class's AtomicString variables & members into String. I'm well aware that this is not ideal, and other ways to make it thread safe should be employed, but once this hurdle to thread safety is passed, everything else seemed to work.I'd like to know if I'm missing any other components that need to be thread-safe in order to evaluate MQs.Currently we cannot represent CSSValues off the main thread because they're RefCounted and we don't want to use thread-safe ref counting. After Oilpan lands, CSSValues will be GarabageCollected, which will let us interact with them off the main thread.Are you sure about this? I thought one of the design ideas with Oilpan was to enable precise GC to run from the message loop, where we could assume that it is not necessary to conservatively scan call stacks. It seems that this would require special treatment if any objects are to be shared across threads.We can check with some Oilpan experts, but my understanding is that every thread that touches GarbageCollected objects will need to register with the heap. The mark phase blocks until all the registered threads have reached safe points (e.g., the top of the event loop). Finalization and sweeping proceeds in parallel on each thread. There's some added complication for worker threads that can have long-running JavaScript that involves the ability to interrupt JavaScript execution.
It's possible we won't want to register the parser thread with the heap, but my guess is that we'll want to be able to handle GarbageCollected objects on the parser thread so that we can malloc up Nodes and potentially do some tree building in the background.
On Sat, Jan 4, 2014 at 10:48 PM, Adam Barth <aba...@chromium.org> wrote:
On Sat, Jan 4, 2014 at 9:00 PM, Darin Fisher <da...@chromium.org> wrote:
On Sat, Jan 4, 2014 at 2:56 PM, Adam Barth <aba...@chromium.org> wrote:
On Sat, Jan 4, 2014 at 12:26 PM, Yoav Weiss <yo...@yoav.ws> wrote:
Following Adam Barth's response on the WHATWG list, I'd like to further understand the complexity of implementing off-the-main-thread MQ evaluation.Similar past concerns have led me to prototype off-the-main-thread MQ evaluation a few months back. As far as I can tell, the only thing preventing such evaluation is the thread-safety of the MediaQueryExp class, and specifically its use of AtomicStrings.Since I wrote the CL as a prototype, I've simply converted the class's AtomicString variables & members into String. I'm well aware that this is not ideal, and other ways to make it thread safe should be employed, but once this hurdle to thread safety is passed, everything else seemed to work.I'd like to know if I'm missing any other components that need to be thread-safe in order to evaluate MQs.Currently we cannot represent CSSValues off the main thread because they're RefCounted and we don't want to use thread-safe ref counting. After Oilpan lands, CSSValues will be GarabageCollected, which will let us interact with them off the main thread.Are you sure about this? I thought one of the design ideas with Oilpan was to enable precise GC to run from the message loop, where we could assume that it is not necessary to conservatively scan call stacks. It seems that this would require special treatment if any objects are to be shared across threads.We can check with some Oilpan experts, but my understanding is that every thread that touches GarbageCollected objects will need to register with the heap. The mark phase blocks until all the registered threads have reached safe points (e.g., the top of the event loop). Finalization and sweeping proceeds in parallel on each thread. There's some added complication for worker threads that can have long-running JavaScript that involves the ability to interrupt JavaScript execution.Oh, I didn't realize the proposal was to have threads join at their message loops. That sounds rather non-ideal in the general case, but for the main isolate, I wonder how many threads will really need to be part of it. (I assume each isolate has its own heap.)
It's possible we won't want to register the parser thread with the heap, but my guess is that we'll want to be able to handle GarbageCollected objects on the parser thread so that we can malloc up Nodes and potentially do some tree building in the background.
If we do this kind of thing, we'll need to be very mindful of the potential jank it introduces when we block the message loops in order to synchronize threads. Hmm...
Is this just for the preload scanner? MQs use a fixed dialect, we should just convert it all to enum tokens (and ints) and use a simple parser so there's no strings.
Currently we cannot represent CSSValues off the main thread because they're RefCounted and we don't want to use thread-safe ref counting.
Here's an example input from the spec that we'd need to be able to handle on the background thread:
(max-width: 30em) 100%, (max-width: 50em) 50%, calc(33% - 100px)
We're going to need a significant fraction of the CSS machine running on the background thread to correctly evaluate that condition.
Is this just for the preload scanner? MQs use a fixed dialect, we should just convert it all to enum tokens (and ints) and use a simple parser so there's no strings.Looking further into MediaQueryExp, it uses AtomicString only for the media feature, so replacing it by an int sounds like a great idea. Since it needs to be able to quickly compare an incoming String to the existing media features, I was thinking of using the String's hash to do an initial comparison, and have some debug ifdefed code that would verify that no collisions occur between the features themselves (since there are currently 43 features, the chances for a collisions are most probably close to nothing). Does that make sense?
On Sat, Jan 4, 2014 at 2:56 PM, Adam Barth <aba...@chromium.org> wrote:
Currently we cannot represent CSSValues off the main thread because they're RefCounted and we don't want to use thread-safe ref counting.Please forgive me if I'm being thick, but looking over the RefCounted code, I can see why you can't pass RefCounted objects between threads, but I can't see why you can't create, own and delete a RefCounted object in the Background HTML parser thread, which as far as I understand, this is what happens when running MediaQueryEvaluator on that thread. What am I missing?
AdamTo unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
[+ager]On Sat, Jan 4, 2014 at 11:55 PM, Darin Fisher <da...@chromium.org> wrote:
On Sat, Jan 4, 2014 at 10:48 PM, Adam Barth <aba...@chromium.org> wrote:
On Sat, Jan 4, 2014 at 9:00 PM, Darin Fisher <da...@chromium.org> wrote:
On Sat, Jan 4, 2014 at 2:56 PM, Adam Barth <aba...@chromium.org> wrote:
On Sat, Jan 4, 2014 at 12:26 PM, Yoav Weiss <yo...@yoav.ws> wrote:
Following Adam Barth's response on the WHATWG list, I'd like to further understand the complexity of implementing off-the-main-thread MQ evaluation.Similar past concerns have led me to prototype off-the-main-thread MQ evaluation a few months back. As far as I can tell, the only thing preventing such evaluation is the thread-safety of the MediaQueryExp class, and specifically its use of AtomicStrings.Since I wrote the CL as a prototype, I've simply converted the class's AtomicString variables & members into String. I'm well aware that this is not ideal, and other ways to make it thread safe should be employed, but once this hurdle to thread safety is passed, everything else seemed to work.I'd like to know if I'm missing any other components that need to be thread-safe in order to evaluate MQs.Currently we cannot represent CSSValues off the main thread because they're RefCounted and we don't want to use thread-safe ref counting. After Oilpan lands, CSSValues will be GarabageCollected, which will let us interact with them off the main thread.Are you sure about this? I thought one of the design ideas with Oilpan was to enable precise GC to run from the message loop, where we could assume that it is not necessary to conservatively scan call stacks. It seems that this would require special treatment if any objects are to be shared across threads.We can check with some Oilpan experts, but my understanding is that every thread that touches GarbageCollected objects will need to register with the heap. The mark phase blocks until all the registered threads have reached safe points (e.g., the top of the event loop). Finalization and sweeping proceeds in parallel on each thread. There's some added complication for worker threads that can have long-running JavaScript that involves the ability to interrupt JavaScript execution.Oh, I didn't realize the proposal was to have threads join at their message loops. That sounds rather non-ideal in the general case, but for the main isolate, I wonder how many threads will really need to be part of it. (I assume each isolate has its own heap.)Each isolate has its own heap, but multiple threads can refer to the same C++ object, like an ExecutionContext or a transferred ArrayBuffer. It's possible we could be careful about how we referenced these objects from multiple threads and trace each thread's heap separately. We discussed this idea a bit in one of the Oilpan sync meetings, but there was some reason folks didn't think this was a good approach.
It's possible we won't want to register the parser thread with the heap, but my guess is that we'll want to be able to handle GarbageCollected objects on the parser thread so that we can malloc up Nodes and potentially do some tree building in the background.
If we do this kind of thing, we'll need to be very mindful of the potential jank it introduces when we block the message loops in order to synchronize threads. Hmm...The way I imagined this working is that we'd park the high-latency threads (like the parser thread) first and only block the main thread when we're actually read to trace the heap. We'd never want low-latency threads (like the compositor or the audio thread) to touch GarbageCollected objects so they'd never need to block. From a code organization perspective, we'd enforce this by preventing blink_platform.dll from depending on blink_heap.dll.Maybe Mads has some more concrete thoughts?
On Mon, Jan 6, 2014 at 12:24 AM, Adam Barth <aba...@chromium.org> wrote:
On Sun, Jan 5, 2014 at 3:09 PM, Yoav Weiss <yo...@yoav.ws> wrote:
On Sun, Jan 5, 2014 at 11:02 PM, Adam Barth <aba...@chromium.org> wrote:
On Sun, Jan 5, 2014 at 1:21 PM, Yoav Weiss <yo...@yoav.ws> wrote:
Is this just for the preload scanner? MQs use a fixed dialect, we should just convert it all to enum tokens (and ints) and use a simple parser so there's no strings.Looking further into MediaQueryExp, it uses AtomicString only for the media feature, so replacing it by an int sounds like a great idea. Since it needs to be able to quickly compare an incoming String to the existing media features, I was thinking of using the String's hash to do an initial comparison, and have some debug ifdefed code that would verify that no collisions occur between the features themselves (since there are currently 43 features, the chances for a collisions are most probably close to nothing). Does that make sense?Yes, we use a similar trick for HTML tag and attribute names.On Sat, Jan 4, 2014 at 2:56 PM, Adam Barth <aba...@chromium.org> wrote:
Currently we cannot represent CSSValues off the main thread because they're RefCounted and we don't want to use thread-safe ref counting.Please forgive me if I'm being thick, but looking over the RefCounted code, I can see why you can't pass RefCounted objects between threads, but I can't see why you can't create, own and delete a RefCounted object in the Background HTML parser thread, which as far as I understand, this is what happens when running MediaQueryEvaluator on that thread. What am I missing?CSSValues are similar to AtomicStrings in the sense that they're shared through a static. In the case of CSSValues, the static is maintained by the CSSValuePool:
We've talked about other mechanisms for removing the CSSValuePool, including introducing the notion of an "immediate" CSS value, much like how many language VMs encode commonly used values in pointers, but moving these values into the Oilpan heap seemed like the better approach.Is there an estimate when CSSValue will move to the Oilpan heap?CSSValue is already in the Oilpan heap on the oilpan branch:We've started landing Oilpan in trunk:Initially, the oilpan code will be behind a compile time flag so that we can carefully evaluate the performance impact. Landing Oilpan is pretty high on our list for the next couple of quarters, but I don't think anyone knows exactly how long it will take.So, hopefully, a few months from now, MQ eval would be implementable off the main thread?
If so, assuming that the use-cases the picture spec resolves are interesting to solve, a path forward may be to implement picture's source selection by joining the main thread (similar to my prototype implementation), and refactor it off-the-main-thread (along with <link rel=stylesheet>'s media evaluation) once oilpan lands.