Memory Management in RubyMotion

2,652 views
2,467 views

Published on

If you are a Rails developer moving to RubyMotion, you need to understand the differences in how memory is managed between the two frameworks. In this talk, we'll discuss how memory management works in iOS, including ARC (Automatic Reference Counting), and how that is different from the garbage collection mechanisms in Ruby MRI. We'll also look at a few "gotchas" that can lead to memory leaks and what you can do to track them down.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,652
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Memory Management in RubyMotion

  1. 1. Memory Management in RubyMotion Some things you should know when coming from Rails Michael Denomy BostonMotion Meetup March 25, 2014
  2. 2. About Me • Software developer @TerribleLabs • Lover of TDD and little ‘a’ agile • Experienced Rails developer, budding RubyMotion developer • mdenomy on twitter, gmail, github • Blog at http://mdenomy.wordpress.com
  3. 3. Memory Management in Ruby (MRI) • You probably haven’t had to think about memory management a lot in Ruby (or other languages). • Ruby automatically allocates memory for you and frees it up using garbage collection mechanism. • Ruby uses a “mark and sweep” algorithm to find objects that are actively being used and ones that are available to be freed up.
  4. 4. Mark and Sweep (the simplified version) • GC walks your code to find “active” objects • Objects no longer used are swept away • MRI 2.1, JRuby, and Rubinius use more sophisticated “generational” mechanisms • Check out Pat Shaughnessy’s “Ruby Under a Microscope” for more GC goodness
  5. 5. Memory Management in iOS • Objective C uses “reference counting” to determine when objects can be freed up. • The number of references to each object is tracked • set to 1 when the object is created • incremented when another object references it • decremented when an object releases it • available to be freed up when count reaches zero
  6. 6. The Dark Ages • Developers manually managed reference count in Objective-C using “Manual Retain-Release MRR” • “retain” incremented reference count • “release” decremented reference count • Under the covers, retain/release still used, but no longer need to manually do it since Automatic Reference Counting (ARC)
  7. 7. Automatic Reference Counting (ARC) • In ARC, calls to retain and release are inserted into the code automatically at compile time • References can be strong or weak • strong - counted as an owner in the “retain-release” cycle • weak - not an owner in “retain-release” cycle. Gets set to nil if object pointed to is released. • Weak references allow us to avoid “retain cycles”
  8. 8. Retain Cycles
  9. 9. What Does This Have To Do With RubyMotion • Still bound by memory management constructs of Objective-C • Need to avoid retain cycles • WeakRef class allows us to create Objective-C weak references to avoid retain cycles
  10. 10. Using WeakRef To Avoid Retain Cycle
  11. 11. How Do We Detect Memory Leaks • Xcode Instruments can be used to examine allocations, memory usage, leaks, etc. • Launch from command line rake profile # Same as profile:simulator rake profile:device # Run a build on the device through Instruments rake profile:device:templates # List all built-in device Instruments templates rake profile:simulator # Run a build on the simulator through Instruments rake profile:simulator:templates # List all built-in Simulator Instruments templates • Can also attach to running instance
  12. 12. Can We Please See Some Code • Very simple example of creating a retain cycle • No extra gems to keep memory “noise” to a minimum • https://github.com/mdenomy/motion-weakref-demo • See README and labels for different conditions • Use Xcode Instruments to examine memory usage
  13. 13. Memory Usage ‘notifier’ tag • No retain cycle because Notifier does not have reference to ToDoItem • Memory increases on create item, but returns to baseline on delete item
  14. 14. Memory Usage ‘retain-cycle’ tag • Notifier has a strong reference to parent ToDoItem, creating retain cycle • Memory increases each call to create item, but is not freed on delete item. Memory leak!!!
  15. 15. Memory Usage ‘weak-ref’ tag • Notifier has a weak reference to parent ToDoItem, so no retain cycle. • Memory usage follows expected pattern of increasing on create item and returning to baseline on delete item
  16. 16. Summary • Reference counting creates the possibility to create memory leaks via retain cycles. • Avoid retain cycles by using WeakRef in RubyMotion when child needs reference to parent • Xcode Instruments can help identify memory leaks or other allocation errors
  17. 17. Questions?
  18. 18. Memory Management in RubyMotion Some things you should know when coming from Rails Michael Denomy BostonMotion Meetup March 25, 2014

×