| Anonymous | Login | Signup for a new account | 2013-05-19 00:01 CEST | ![]() |
| Main | My View | View Issues | Change Log | Roadmap |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | |||||||
| 0005842 | OCaml | OCaml runtime system | public | 2012-12-04 07:33 | 2013-01-15 14:03 | |||||||
| Reporter | markghayden | |||||||||||
| Assigned To | frisch | |||||||||||
| Priority | high | Severity | major | Reproducibility | always | |||||||
| Status | resolved | Resolution | no change required | |||||||||
| Platform | OS | OS Version | ||||||||||
| Product Version | 4.00.1 | |||||||||||
| Target Version | Fixed in Version | |||||||||||
| Summary | 0005842: GC Compaction is only partial | |||||||||||
| Description | When I call Gc.compact do not appear to release all unused spaced on the heap. Our software does make use of weak references and finalizers. It uses a large number of 3rd party libraries and external C code. Calling Gc.full_major and/or Gc.compact multiple times does not seem to affect the situation significantly. This appears to happen reliably in my app. My Ocaml software (www.seaiq.com) runs on devices (Apple iPads and iPhones) with limited memory and often receives memory warnings from the operating system. In such situations, a failure to release sufficient memory can cause the app to be killed. The fact that compaction appears to only release part of the free memory and often leaves as much or more free memory chunks as live memory is quite problematic. Are there known situations where free space is not released as part of a compaction? Please let me know if I'm misinterpreting the purpose of Gc.compact or if there is something else my app needs to do in order to actually release all free memory. Thanks! | |||||||||||
| Steps To Reproduce | This happens reliably in my app. I don't have a small test program at this point. I'd like to know this is not a known issue or expected behavior before spending the time to generate one. | |||||||||||
| Additional Information | Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: PLOTTER_GEN:memory_warning:begin Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: minor_words=98085359 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: promoted_words=4635560 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: major_words=20002328 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: minor_collections=418 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: major_collections=33 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: heap_words=4527104 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: heap_chunks=28 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: live_words=4041179 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: live_blocks=563299 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: free_words=485914 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: free_blocks=24829 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: largest_free=61444 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: fragments=11 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: compactions=7 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: top_heap_words=7720960 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: PLOTTER_GEN:compacting:begin Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: PLOTTER_GEN:compacting:end Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: minor_words=98093975 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: promoted_words=4635560 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: major_words=20002781 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: minor_collections=418 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: major_collections=35 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: heap_words=1142784 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: heap_chunks=9 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: live_words=611600 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: live_blocks=85487 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: free_words=531182 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: free_blocks=6 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: largest_free=126976 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: fragments=2 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: compactions=8 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: top_heap_words=7720960 Dec 4 10:19:32 unknown SEAiq[4570] <Warning>: PLOTTER_GEN:memory_warning:end | |||||||||||
| Tags | No tags attached. | |||||||||||
| Attached Files | ||||||||||||
Notes |
|
|
(0008558) doligez (manager) 2012-12-04 11:17 edited on: 2012-12-04 11:18 |
Unless you have changed the space_overhead setting from its default value of 80, the GC (including the compactor) tries to maintain the heap_words/live_words ratio at 1.8 (= 1 + space_overhead/100). In your sample, the ratio is 1.87, pretty close to the target. You can set space_overhead lower, but this is a space/time trade-off: the lower the overhead, the more time you will spend in the GC. |
|
(0008571) markghayden (reporter) 2012-12-05 18:24 |
Thanks for the explanation. When I use the following code, I get the desired results (almost all free memory is released). It might help to clarify the behavior in the documentation for the function. From my perspective this is resolved. thanks! Mark let do_gc_compact () = let control = Gc.get () in let overhead = control.Gc.space_overhead in control.Gc.space_overhead <- 1 ; Gc.set control ; Gc.compact () ; control.Gc.space_overhead <- overhead ; Gc.set control ; ;; |
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2012-12-04 07:33 | markghayden | New Issue | |
| 2012-12-04 11:17 | doligez | Note Added: 0008558 | |
| 2012-12-04 11:17 | doligez | Status | new => feedback |
| 2012-12-04 11:18 | doligez | Note Edited: 0008558 | View Revisions |
| 2012-12-05 18:24 | markghayden | Note Added: 0008571 | |
| 2012-12-05 18:24 | markghayden | Status | feedback => new |
| 2013-01-15 14:03 | frisch | Status | new => resolved |
| 2013-01-15 14:03 | frisch | Resolution | open => no change required |
| 2013-01-15 14:03 | frisch | Assigned To | => frisch |
| Copyright © 2000 - 2011 MantisBT Group |