Граф коммитов

11 Коммитов

Автор SHA1 Сообщение Дата
Gabriele Svelto 2bc88d71e0 Bug 1614933 - Gather content processes' crash annotations at exception time instead of using IPC; r=froydnj
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.

This has a number of benefits:

* we have one less channel to exchange data between content processes and
  the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
  changes
* we won't truncate annotations anymore if we run out of space in the shared
  segment.
* we don't need delayed annotations anymore, so we can get rid of the
  associated machinery

As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.

Differential Revision: https://phabricator.services.mozilla.com/D62586

--HG--
extra : moz-landing-system : lando
2020-04-08 06:55:40 +00:00
Brindusan Cristian 4646c1f41f Backed out 2 changesets (bug 1614933) for bc failures at browser_tabicon_after_bg_tab_crash.js.
Backed out changeset 59503d3a702f (bug 1614933)
Backed out changeset 578c8ba9598f (bug 1614933)
2020-03-22 17:30:07 +02:00
Gabriele Svelto 322404bebb Bug 1614933 - Gather content processes' crash annotations at exception time instead of using IPC; r=froydnj
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.

This has a number of benefits:

* we have one less channel to exchange data between content processes and
  the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
  changes
* we won't truncate annotations anymore if we run out of space in the shared
  segment.
* we don't need delayed annotations anymore, so we can get rid of the
  associated machinery

As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.

Differential Revision: https://phabricator.services.mozilla.com/D62586

--HG--
extra : moz-landing-system : lando
2020-03-21 17:13:08 +00:00
Boris Zbarsky 3ae961a2da Bug 1589561. Factor out idle handling from PrioritizedEventQueue. r=smaug
We could try to move the EnforcePendingTaskGuarantee() bit into
PeekIdleDeadline, but then we'd need to check HasReadyEvent() on
mDeferredTimersQueue and mIdleQueue before we possibly unlock the mutex under
PeekIdleDeadline, and it's not clear that that state cannot change once the
mutex is unlocked...

The EnsureIsActive() call at the end of GetIdleDeadlineInternal in the !aIsPeek
case only makes sense if there are in fact idle tasks available to run when
GetDeadlineForIdleTask is called, because otherwise it would incorrectly set us
active when we are not running any tasks.

Differential Revision: https://phabricator.services.mozilla.com/D49696

--HG--
rename : xpcom/threads/PrioritizedEventQueue.cpp => xpcom/threads/IdlePeriodState.cpp
rename : xpcom/threads/PrioritizedEventQueue.h => xpcom/threads/IdlePeriodState.h
extra : moz-landing-system : lando
2019-10-20 15:08:44 +00:00
Cosmin Sabou 68c31e0e43 Backed out changeset 798bab343a0a (bug 1589561) for turning bug 1586420 into permafail. CLOSED TREE
--HG--
extra : amend_source : 1c548e9a10e27ff6a50d98f15a701dcd1c717544
2019-10-18 23:04:26 +03:00
Boris Zbarsky 4a394c3f69 Bug 1589561. Factor out idle handling from PrioritizedEventQueue. r=smaug
We could try to move the EnforcePendingTaskGuarantee() bit into PeekIdleDeadline, but
then we'd need to check HasReadyEvent() on mDeferredTimersQueue and mIdleQueue
before we unlock the mutex and PeekIdleDeadline, and it's not clear that that
state cannot change once the mutex is unlocked...

The EnsureIsActive() call at the end of GetIdleDeadlineInternal in the !aIsPeek
case only makes sense if there are in fact idle tasks available to run when
GetDeadlineForIdleTask is called, because otherwise it would incorrectly set us
active when we are not running any tasks.

Differential Revision: https://phabricator.services.mozilla.com/D49696

--HG--
rename : xpcom/threads/PrioritizedEventQueue.cpp => xpcom/threads/IdlePeriodState.cpp
rename : xpcom/threads/PrioritizedEventQueue.h => xpcom/threads/IdlePeriodState.h
extra : moz-landing-system : lando
2019-10-18 17:28:50 +00:00
Olli Pettay 1d1349d4bf Bug 1563063 - Cross-process idle handling, r=farre
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)

Differential Revision: https://phabricator.services.mozilla.com/D45162

--HG--
extra : moz-landing-system : lando
2019-09-24 14:33:57 +00:00
arthur.iakab a595388e84 Backed out changeset 5ed078313a10 (bug 1563063)for causing browser-chrome failures on browser_test_feature_preferencereads.js a=backout 2019-09-21 16:36:09 +03:00
Olli Pettay a1f7c1bbdf Bug 1563063 - Cross-process idle handling, r=farre
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)

Differential Revision: https://phabricator.services.mozilla.com/D45162

--HG--
extra : moz-landing-system : lando
2019-09-20 19:31:58 +00:00
Bogdan Tara 7e0aba7d00 Backed out changeset b0c0887e223c (bug 1563063) for browser_test_feature_preferencereads and browser_test_profile_multi_frame_page_info failures CLOSED TREE 2019-09-19 23:18:06 +03:00
Olli Pettay bcf140f437 Bug 1563063 - Cross-process idle handling, r=farre
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)

Differential Revision: https://phabricator.services.mozilla.com/D45162

--HG--
extra : moz-landing-system : lando
2019-09-18 23:53:42 +00:00