3 ms·
Its an important change, but not huge, at least not yet: it's not yet integrated in the GC, which means you have to explicitly request it. And most of the fragm
by chucke 7y ago
Its an important change, but not huge, at least not yet: it's not yet integrated in the GC, which means you have to explicitly request it. And most of the fragmentation comes anyway from the allocations heap. That being said, I think this will improve in the coming releases.
- ultrarunner 7y agoWhat criteria should be monitored to request compaction in a long-running process? Is a timer sufficient (at what interval?) or are there other tools available in Ruby to make that decision?
- brandur 7y agoIt's likely to be most useful for anyone using a Unicorn-style process forking model in Ruby. You call `GC.compact` in the parent right before forking off your child processes and because the memory in the children are copy-on-write (COW), it lets them share memory with their parent far longer than they normally would be able to. Any change in a page (i.e. an object allocated or deallocated) causes it to be copied to a child process, and because previously pages were a mix of objects of all kinds of longevity and slots which may be empty or used, children tended to copy their parent's entire memory space very quickly. Running a GC and compact before forks improves the likelihood that shared pages are mostly full of still-in-use, longer-lived objects, and gives the COW strategy a fighting chance.