Last Comment Bug 818265 - Flash NPP_Destroy takes ~90ms. Impeding shutdown, navigation.
: Flash NPP_Destroy takes ~90ms. Impeding shutdown, navigation.
Status: NEW
[Snappy:P1]
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All All
: -- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://developer.mozilla.org/en/docs...
Depends on:
Blocks: shutdown-faster
  Show dependency treegraph
 
Reported: 2012-12-04 13:56 PST by Benoit Girard (:BenWa)
Modified: 2013-08-14 23:50 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Benoit Girard (:BenWa) 2012-12-04 13:56:38 PST
Startup report:
https://people.mozilla.com/~bgirard/startup_report/report.html#PluginInstanceParent::Destroy

This currently list 10 shutdown profiles sorted from longest to shortest time spent in PluginInstanceParent::Destroy recorded on my system. Click on the profile will preview the profile + highlight the function.

Filing this bug even if I'm not sure if there's a ton we can do without a NPAPI change. Any ideas Benjamin?
Comment 1 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2012-12-04 13:59:02 PST
We could TerminateProcess the plugin-container. I don't know whether that would totally destroy Flash data structures. Other than that, don't expect magic bullets.
Comment 2 Benoit Girard (:BenWa) 2012-12-04 14:08:42 PST
TerminateProcess? Do you just mean kill the plugin process?

Would it be possible to shutdown the plugin process async and have any other NPAPI call fail?
Comment 3 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2012-12-04 14:35:14 PST
Yes, I mean killing the plugin process. It would be very difficult to asynchronously shut down the plugin process because it almost certainly continues to make calls into the browser as part of shutdown, and those would all need to be stubbed out with some kind of error message (and those error might cause additional instability). I think that if we're going to experiement with this, terminating the process is the better choice.

We could ask Adobe whether we they provide a new "shutting down now" API which would immediately save persistent state and then allow us to terminate the process more safely...
Comment 4 Vladan Djeric (:vladan) 2012-12-04 14:55:20 PST
Plugin shutdown time measures https://bugzilla.mozilla.org/show_bug.cgi?id=706647
Comment 5 Benoit Girard (:BenWa) 2012-12-05 14:56:33 PST
Note that this measurement is very different then what my profile is measuring. It appears that we spend a lot of time destroying plugin instances on shutdown not the plugin process.
Comment 6 Benoit Girard (:BenWa) 2012-12-06 07:12:28 PST
I did more research on this. I can reproduce this on a fast windows machine as well as on mac. I confirmed that the slow down was coming from NPP_Destroy. Skipping that call makes the problem go away but will leak resources and will not let the plugin persist data. Leaking resource is okay on an optimized shutdown but we still need to persist data. This problem is particularly bad on shutdown because it scaled linearly with the number of open tab. i.e. 10 youtube tabs means you've added 1 second to your shutdown time.

Note You need to log in before you can comment on or make changes to this bug.