On Sunday, August 26, 2018 at 7:43:20 PM UTC-4, Matthew Flatt wrote: > > > Racket's memory manager does not immediately release pages back to the > OS (i.e., unmap them) after a GC. In its current configuration, the GC > releases a page at the beginning of a major GC only if the page was > unused at the *start* of the previous GC. So, there's roughly a lag of > 2 GCs to unmap a page that becomes unused as a result of a GC. That > policy reduces back-and-forth with the OS on page allocation, which can > be relatively costly. > > I think this lag explains exactly what I'm seeing. I ran (collect-garbage 'major) twice in a row and it freed up several hunderd MBs that it wasn't freeing after just one collection. This should work for my needs!
Then again, at the end of a GC, if there are more than 4 times as many > mapped pages as currently in use, then all unused pages are immediately > released. That rule is an attempt to keep actual use and mapped pages > from getting too far out of sync. > > I think I am probably close but not quite at the 4x threshold. I'm happy to hear this, because I don't need to worry overmuch about memory usage growing too much larger than it already is without memory being freed. Thanks again for the explanation. I'm assuming there aren't any GC parameters for this that I can tweak from application code, but please let me know if there are! -- Jonathan -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
