Open Bug 338645 Opened 19 years ago Updated 3 years ago

Wrap Gecko event processing in an auto release pool

Categories

(Core :: Widget: Cocoa, defect, P3)

Product:
Core
Component:
Widget: Cocoa
Platform:
x86_64
macOS
Type:
defect

Tracking

()

People

(Reporter: mark, Unassigned)

References

(Blocks 1 open bug)

Details

Right now, we've really only got two autorelease pools working: there's a pool for each native event, and for everything else, there's the root pool. Too many things are autoreleased to the root pool. I want to get us to the point where only true application-scope objects that need to live for the life of the application are autoreleased to that pool. We should at least provide shorter-lived pools for Gecko events. In the past, Gecko events were handled on native event fetch, with a pool in place, so they wouldn't be autoreleased to the root pool. The new thread architecture (bug 326273) changed this. I think we only need to guarantee an autorelease pool for things in widget/src/cocoa that happen on Gecko events on the main thread. If there's ObjC/Cocoa code that doesn't meet these criteria, it should still provide its own pool, as in bug 338041.
Flags: blocking1.9?
Does this actually fix anything or is it just cleaner code?
It would fix a type of memory leak that I suspect is not uncommon right now.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
We could afford to use autoreleasepools in lots of places in nsCocoaWindow/nsChildView - they are very, very cheap to create (http://www.mikeash.com/blog/pivot/entry.php?id=19) and would help us use the memory more efficiently. So let's just add pools to some major places where we communicate down to gecko, from nsChildView/nsCocoaWindow. One obvious such place would be for example DispatchEvent().
Flags: wanted1.9+
Whiteboard: [wanted-1.9]

The bug assignee didn't login in Bugzilla in the last 7 months.
:spohl, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: mark → nobody
Flags: needinfo?(spohl.mozilla.bugs)

Markus, could I ask you to weigh in here on what should happen with this bug?

Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(mstange.moz)

Interesting bug! It makes sense, but I haven't seen any complaints about too-high temporary memory usage from autoreleased objects, so that's probably why we haven't done it before.
We're also in a very different today where most of the ObjC APIs are only called in the parent process and web content is running in the content process. Though we do use some ObjC APIs in the content process, for example for stuff relating to fonts. It would be interesting to see how the content process event loop manages its auto release pools.

Hmm, I just got an allocation profile and didn't see any deallocations from event loop auto release pools in the content process. We may in fact have some leaks there. This warrants investigation.

Flags: needinfo?(mstange.moz)
Summary: Provide better (more strategic) autorelease pools → Wrap Gecko event processing in an auto release pool

Thank you!

Severity: normal → S4
Priority: -- → P3
Hardware: PowerPC → x86_64
You need to log in before you can comment on or make changes to this bug.