From: Brett v. de S. <bv...@as...> - 2010-02-27 15:07:37
|
>If this is "just" a performance issue, then a bigger nursery and >making higher GENERATION-BYTES-CONSED-BETWEEN-GCS for the top-few >generations will probably help. Doesn't work, see bug https://bugs.launchpad.net/sbcl/+bug/529014 Instead, I have been changing the parameters in gencgc.c itself: josiah> diff sbcl-1.0.35/src/runtime/gencgc.c gencgc.c_original 4625c4626 < generations[i].bytes_consed_between_gc = i<3?2*1024*1024:100*1024*1024; --- > generations[i].bytes_consed_between_gc = 2000000; However, this doesn't quite work because the initial value of gc_trigger is too small. If I also change the initial value of gc_trigger: josiah> diff sbcl-1.0.35/src/runtime/gencgc.c gencgc.c_original 4621c4622 < generations[i].gc_trigger = i<3?2*1024*1024:200*1024*1024; --- > generations[i].gc_trigger = 2000000; 4625c4626 < generations[i].bytes_consed_between_gc = i<3?2*1024*1024:100*1024*1024; --- > generations[i].bytes_consed_between_gc = 2000000; Then sbcl crashes on startup. >See section 7.13 in the fine manual >(assuming you have SBCL 1.32.33 or newer.) :-) >If you are running out of heap space, running a full collection after >a session has closed is likely to help -- but this has obvious >performance implications. I will try this, just to see what happens. >[ Actually, one GC toggle that we don't have but could is SCHEDULE-GC >where you could specify the depth of the next GC, so that when a >session ends you could do (SCHEDULE-GC :FULL) -- so that next time GC >runs, it will be a full GC. Need to think about this. ] > >Other alternatives are: > >* Use stack allocation for short-lived data, so it will not cause >promotion of older objects so fast. This may require restructuring >control flow, obviously. I have been looking at this. But it doesn't solve the big problem of the 1MB of data that persists over the course of rougly 15 minutes. >* Structure your large data to minimize the number of pointers: if you >can pack things into eg. (SIMPLE-ARRAY (UNSIGNED-BYTE 32) 1), it will >mean less work for the GC. No dice. Most of the memory is for lisp expressions in our AI system, structs, etc. The data structure is pretty complicated. > >* Keep long-lived data outside the heap: either in foreign memory, or >store it in a DB. Then you can release/delete it when you want. See above. BTW, if you want to see our application in action, you can try it out at: http://gideon.eas.asu.edu/web-UI/login.html Brett |