Hi Pozdnyakov,
Firstly, I would like to thank for your cautious attitude upon this PR. Please check my comments below; your feedback will be highly appreciated.  

[1]  About where 2 secs comes from?

As I replied to alexshalamov, 
'2 seconds' is not the only choice for our case, we may set other values for these two variables. The reason that I set it as '2s' is based on the following consideration,
a) The value should not be too large, we hope the main document could be closed in time if it has been idle for some time.
b) At the same time the value could not be too small. If value is too small, it may cause wrong behavior. For example, if main_document_idle_time_ is set as 100ms, main_document_suspending_time_ also 100ms,
0.0s, open a window A;
0.5s, close the window A;
1s, open a new window B.
For this case, window B may be never created, because the main document may be closed around at 0.7s.

Actually there is more background information: The first version is not like this. When I submitted the first PR of this patch, I followed the Chromium method to set the two variables, in detail, sets the default value of main_document_idle_time_ with 10 sec, and sets default value of main_document_suspending_time_ with  5 sec; Also provides a method to reset these values by adding command line options. From Kenneth’s feedback,  these values are too large, also the command line option seems redundant.  

So finally I removed the command line option and give 2 secs for these variables.  It doesn’t mean this is the only choice, please feel free to comment if you have any suggestion on this.

[2] About the spec ‘When the main document is not executing any script, has no pending callbacks, and no open windows, the runtime can decide to unload the main document’.

Frankly speaking, I didn’t consider too much about the cases of ‘no executing script’ and ‘no pending callbacks’. I mainly focused on ‘the no open window’ case, because this is the most common case for Crosswalk applications. I re-evaluate current status of this PR, 

(a) ‘no open window case’: of coz we totally support it in this PR.

(b) ‘no executing script’: IMO we also support it. In detail, if the JS code is still executing in render thread, the render process main loop won’t be idle. As a result, when runtime process send ‘Shouldsuspend’ message to render process, the ‘ShouldsuspendAck’ message won’t be replied immediately. Instead, the ACK message will be sent until executing JS script is finished. 

(c)’no pending callback’ case: It is not supported yet. Maybe one scenario is ‘network request’. I took a look of Chromium implementation, seems this will need lots of code change. Also could you please provide more scenarios of ‘no pending callback’ cases? I am not familiar with this.  

(d) about comment, ’it does not look like expected behavior: it just checks that the main loop is working fine (it did not get stuck inside some handler), but it does not mean the process is idle, note that the given approach it doesn't take into consideration other threads inside the renderer process.’
I think one case is web worker, which runs in a separate thread inside render process.  In this case, the web worker should be handled in onSuspend() callback by developer, since it is also created  by developer, seems it is not our duty to manage it internally.
 
To summarize, all these cases should be supported, while it doesn’t mean we should support all of them in one time. This PR is the major framework to implement the spec, cases likes ‘no pending callbacks’ will be fully investigated and implemented, also they won’t break current framework. But we need more time to implement this, I am afraid we can’t meet the M3 deadline. How do you think?