How to trigger internal actions

[Kenichi Ishibashi]

Hi telemetry@ and pfeldman@,

MemoryBackend.SimulateMemoryPressureNotification() is implemented by using the DevTools debugging protocol. Is this still the way to do a similar thing?

We are planning to replace MemoryPressureListener (which is broken in some ways) with a new mechanism called MemoryCoordinator. Here is a V0 implementation plan. I think that telemetry + TBMv2 seems a right choice to measure the impact of throttling memory allocation and/or purging memory while figuring out strategies for better memory coordination. Until we have some strategies, we need a way to trigger notifications from outside chromium like MemoryBackend.SimulateMemoryPressureNotification(). Can we do that without using the debugging protocol? If the answer is no, it would mean that we need to either:

(1) add a new command for the debugging protocol (e.g. Memory.simulateMemoryCoordinatorEvent)

(2) associate Memory.SimulateMemoryPressureNotification with MemoryCoordinator instead of MemoryPressureListener

I'd prefer (1) if DevTools folks think it's acceptable because (2) requires a compile time flag. Another downside of (2) is that we can't send a signal to stop throttling memory allocation, which would make it difficult to develop strategies for better memory coordination.

Thanks,

[Juan Antonio Navarro Pérez]

+chrome-memory-lon 

--
You received this message because you are subscribed to the Google Groups "telemetry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to telemetry+...@chromium.org.

[Nat Duca]

Some flavor of option 2 seems ideal --- when we did the Memory.Simulate interface it was supposed to be future compatible with these kinds of use cases.

Petr did a lot of that initial work, I recall. So, maybe you could sync with Petr to find some concrete unified solution and then re-share with us what you two come up with?

+chrome-memory-lon 

To unsubscribe from this group and stop receiving emails from it, send an email to telemetry+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "chrome-memory-lon" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-memory-lon+unsubscribe@google.com.
To post to this group, send email to chrome-m...@google.com.
To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/chrome-memory-lon/CA%2BbEg-YiUcypoT-jB_WbA7xAhHkDa9Pv7HnrqVMveumQVmNeaQ%40mail.gmail.com.

[Pavel Feldman]

Triggering events in the controlled environment should be done using remote debugging. You can definitely add commands there. Having said that, I'd defer it to Nat and Petr as to whether you need new command(s) or should unify and reuse existing one(s).

Pavel

On Tue, May 31, 2016, 09:37 Nat Duca <nd...@google.com> wrote:

Some flavor of option 2 seems ideal --- when we did the Memory.Simulate interface it was supposed to be future compatible with these kinds of use cases.

Petr did a lot of that initial work, I recall. So, maybe you could sync with Petr to find some concrete unified solution and then re-share with us what you two come up with?

On Tue, May 31, 2016 at 2:07 AM, Juan Antonio Navarro Pérez <per...@google.com> wrote:

+chrome-memory-lon 

On Tue, May 31, 2016 at 6:34 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

Hi telemetry@ and pfeldman@,

MemoryBackend.SimulateMemoryPressureNotification() is implemented by using the DevTools debugging protocol. Is this still the way to do a similar thing?

We are planning to replace MemoryPressureListener (which is broken in some ways) with a new mechanism called MemoryCoordinator. Here is a V0 implementation plan. I think that telemetry + TBMv2 seems a right choice to measure the impact of throttling memory allocation and/or purging memory while figuring out strategies for better memory coordination. Until we have some strategies, we need a way to trigger notifications from outside chromium like MemoryBackend.SimulateMemoryPressureNotification(). Can we do that without using the debugging protocol? If the answer is no, it would mean that we need to either:

(1) add a new command for the debugging protocol (e.g. Memory.simulateMemoryCoordinatorEvent)

(2) associate Memory.SimulateMemoryPressureNotification with MemoryCoordinator instead of MemoryPressureListener

I'd prefer (1) if DevTools folks think it's acceptable because (2) requires a compile time flag. Another downside of (2) is that we can't send a signal to stop throttling memory allocation, which would make it difficult to develop strategies for better memory coordination.

Thanks,

--
You received this message because you are subscribed to the Google Groups "telemetry" group.

To unsubscribe from this group and stop receiving emails from it, send an email to telemetry+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "chrome-memory-lon" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chrome-memory-...@google.com.

[Petr Cermak]

[adding other folks back so that everyone can have a full picture and this thread is stored in the mailing lists; +chrisha]

Hi Kenichi,

Thanks for your email. My feeling is that in the long run (i.e. once MemoryCoordinator is mature enough), it would be better to have a dedicated DevTools API for the memory coordinator, e.g. Memory.dispatchCoordinatorEvent, as you suggested, and remove the existing APIs (once MemoryCoordinator fully replaces MemoryPressureController).

However, having been through the process of adding the existing APIs (Memory.simulatePressureNotification and Memory.setPressureNotificationsSuppressed) and the subsequent "the API doesn't capture use case X" moment, I'm a little worried about doing this straightaway. If you do that, you are very likely to find that you need to re-design the whole API in a couple of weeks/months and, as we all know, changing an existing API is very cumbersome (especially if it has lots of customers, which the memory coordinator very likely will have).

In the meantime, I think it would make the most sense to recycle the existing API (if possible). I can see that you need to trigger 3 states, which Memory.simulatePressureNotification unfortunately doesn't provide. Here are the possible solutions I can think of:

1. Unless you need to keep the ability to suppress pressure notifications, you could theoretically do the following (as a temporary hack):
• Memory.setPressureNotificationsSuppressed(false) → Unthrottle
• Memory.setPressureNotificationsSuppressed(true) → Throttle
• Memory.simulatePressureNotification("critical") → Purge
2. Another option is to add an extra option to the PressureLevel DevTools enum. Again, it's not ideal, but probably less risky than adding a whole new API.

If neither of the above options seems right, I'm afraid there's no other option but to add a new API straightaway.

Hope this helps.

Petr

On Thu, Jun 2, 2016 at 2:05 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

(-other folks)

Hi Petr,

Do you have any preference on this? Specifically, we want to trigger

- Throttle

- Unthrottle

- Purge

events to chrome from telemetry (for now). Nat likes option (2) but my concern of the option are:

- We need to add a compile time flag in content/browser/devtools/protocol/memory_handler.cc to associate SimulatePressureNotification to MemoryCoordinator (which we are going to implement) instead of  MemoryPressureControllerImpl

- We can't map 'moderate' nor 'critical' to 'Unthrottle'

So I think it would be better to add a new message like Memory.dispatchCoordinatorEvent to the remote debugging protocol (option 1). WDYT?

[Kenichi Ishibashi]

Thanks Petr, Pavel and Nat for suggestions and clarifications. As Petr said we are very likely to change the APIs so Petr's suggestion makes sense to me. I still slightly prefer adding a new remote debugging API (and deprecate MemoryPressureController) because we would end up having a trouble to map existing APIs into what we want to do with MemoryCoordinator, but I'll try to follow Petr's suggestion first.