Folks, I've found that native / Java task ordering is effectively random, even without Message.setAsynchronous(true). This is mostly FYI, but I wonder if this can help us to simplify Android-related message loop code.

Another concern is that I feel there are cases where number of unprocessed messages posted from ScheduleWork() grows over time, affecting memory usage. Can't think of a concrete example though. There are 99 Message-related OOM crashes in 63.*: https://crash.corp.google.com/browse?q=product.Name%3D%27Chrome_Android%27%20AND%20product.Version%20LIKE%20%2763%25%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%20LIKE%20%27%25OutOfMemoryError%25Message%25%27&sql_dialect=dremelsql&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D&stbtiq=&reportid=e5c07ac3e04d0467&index=0#0

Assuming ordering between delayed and non-delayed tasks? That's pretty sketchy on a regular message loop too. Hopefully nothing relies on ordering.

> Another concern is that I feel there are cases where number of unprocessed messages posted from ScheduleWork() grows over time, affecting memory usage.

Hmm, I'm curious what causes that exactly? Are delayed tasks causing more of these messages than strictly necessary?

The issue is that delayed tasks mess up ordering of non-delayed native / Java tasks. Some comments in the code seem to imply that we wanted to guarantee some Java / native ordering, but it's effectively random. I.e. we can probably simplify some code. And also we should not call ScheduleWork() for delayed tasks.

I did find it pretty confusing that posting a delayed task calls ScheduleWork(), and (usually) also ScheduleDelayedWork(). It seems like ScheduleDelayedWork is assumed to always be called from the message pump's thread. When you say we shouldn't call ScheduleWork for delayed tasks, are you implying we should change that assumption and call ScheduleDelayedWork directly on the calling thread?

In my CL (https://chromium-review.googlesource.com/c/chromium/src/+/751322) I did find that a few things depended on Java/native ordering and are currently racy - not many though, so I'll be fixing those regardless of whether or not my CL goes through.

The other thing my CL does is make always_schedule_work_ nearly free, as it only needs to increment an atomic integer for each task posted after the first, but it would be easy enough to implement without always_schedule_work_ and save a very small amount of time.

Using the native looper API we can also not block native tasks on all of the java tasks in the queue if we do want to run multiple native tasks each time the looper calls us back.

With https://bugs.chromium.org/p/chromium/issues/detail?id=780100, we no longer call ScheduleWork() for all tasks.

We now run all of the available native tasks before returning control to the java looper to run java tasks.

I'm not sure if there's anything actionable left in this bug? Maybe we should close it? I've heard there's also ongoing work to post critical java tasks natively to get them to run earlier with proper ordering/priority.

> We now run all of the available native tasks before returning control to the java looper to run java tasks.

That's probably not desirable. This was actually the original behavior, and we had to change it so that native and java tasks are fair, so that java tasks are not penalized when there are a lot of native ones, causing performance issues. This was more important for webview where the UI thread is shared with the app, but I don't know how much java stuff runs in clank these days..

We're currently looking at ways to make C++/Java task ordering somewhat fairer. The current thinking is that we'll treat C++ and Java identically (as in, they end up in the same FIFO) and apply normal task prioritization logic between them. The exception is non-Clank Java work which we can't easily redirect to the scheduler (short of class loader hacks), so we may need to keep round-robining them with other work. Details TBD.

> That's probably not desirable. This was actually the original behavior, and we had to change it so that native and java tasks are fair, so that java tasks are not penalized when there are a lot of native ones, causing performance issues. This was more important for webview where the UI thread is shared with the app, but I don't know how much java stuff runs in clank these days..


For what it's worth, startup profiling on Go devices showed no change in startup times, and while there were a small number of tasks whose order was reversed, the ordering of those tasks didn't seem to have an impact on startup time.

As for trying to be fairer for C++/Java task ordering, I did have a version of my patch where I returned control to the looper after every native task, so it would go back and forth between java and native tasks, but it turned out to be really complicated as a lot of java code actually relied on the native tasks running first.

The previous effort to make things fairer was https://bugs.chromium.org/p/chromium/issues/detail?id=250924

Also mentioned in that bug that I didn't think about, if you run all the native tasks before returning to java, you kind of run the risk of causing more ANRs

If we want to avoid ANRs, we could always do something like have a max time we spend in native code before returning control to the looper. Not possible to strictly enforce, if we have an individual task that takes a long time to run, but we could probably do a reasonable job there.

In fact I think what would help a lot here is what skyostil mentioned. If all (most) of our own java tasks are posted through the native queue, we could return control to the looper and have a much higher chance of, say, handling input.

Unfortunately that doesn't help webview where most of the java tasks are posted by the app, and we have no control how the posting happens.

Possibly Webview should have an entirely different message pump implementation in that case, with different priorities?

Do we have perf benchmarks or sample poorly-behaved webview apps to actually test changes on?

Not really. :/

Anyway, the behavior before  crbug.com/250924  was preferring java tasks over native, which then caused a bad behaving app to starve webview work (mostly native). The current behavior now is to prefer native over java, so as long as webview doesn't behave, it's probably not a huge deal. And hopefully we don't ever misbehave..

Well, looks like this was a ~15% startup time improvement on some go phones :) https://bugs.chromium.org/p/chromium/issues/detail?id=862984

Nice work!