Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[iOS] Add autorelease pool for each run loop for JS Thread #27395

Closed
wants to merge 1 commit into from

Conversation

zhongwuzw
Copy link
Contributor

Summary

Fixes #27327 , we need to create autorelease pool for each run loop in secondary thread, otherwise application may have memory issues. More details can refer to CreatingThreads
image

Changelog

[iOS] [Fixed] - Add autorelease pool for each run loop for JS Thread

Test Plan

Example can be found in #27327. No memory spikes any more.

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Dec 3, 2019
@zhongwuzw zhongwuzw requested a review from RSNara December 3, 2019 08:39
@react-native-bot react-native-bot added Platform: iOS iOS applications. Bug labels Dec 3, 2019
@zhongwuzw zhongwuzw requested a review from hramos December 6, 2019 10:05
Comment on lines +39 to +44
CFRunLoopPerformBlock(m_cfRunLoop, kCFRunLoopCommonModes, ^{
// Create an autorelease pool each run loop to prevent memory footprint from growing too large, which can lead to performance problems.
@autoreleasepool {
func();
}
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will impact pre-TurboModule system as well. The OOM is only when TM is used right? So I think the fix should be done somewhere around the caller of runAsync that's specific to TM?

In other words, this code doesn't leak memory pre-TM, why is that? If we can find the logic in the old system that prevents the leak, we should apply the same fix for TM. So this PR might not address the TM-specific reason for the leak.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fkgozali Actually, pre-TurboModule also has the issue, the reason why pre-TurboModule seems not have is it not creates giant autorelease objects, for example, TurboModule create one NSInvocation (autorelease object) for each method call, but pre-TurboModule only create one by cache. So pre-TurboModule just hidden the issue in @sjchmiela 's demo, but actually it also has if module method create many autorelease objects.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but pre-TurboModule only create one by cache

I see, good catch. I think we should aim to get the caching ideally, but that may be out of scope for this issue. If you're up for some refactoring, that would be helpful :).

Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fkgozali has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

@react-native-bot
Copy link
Collaborator

This pull request was successfully merged by @zhongwuzw in 948cbfd.

When will my fix make it into a release? | Upcoming Releases

@react-native-bot react-native-bot added the Merged This PR has been merged. label Dec 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Merged This PR has been merged. Platform: iOS iOS applications.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Obj-C++ TurboModules leak memory – 600 bytes per a method call
4 participants