Il 27/10/2012 21:00, Holger Hans Peter Freyther ha scritto: > Dear Paolo, > > I have some questions regarding the memory management of GST. There > are two unrelated questions below. > > 1.) 'reducing' memory usage. Is there an easy way to reduce the > memory footprint (e.g. less objects, less oldspace.. etc)? Would it > make sense to introduce a 'small' profile for gst and gst-remote? > Maybe another profile for a lot of memory as well.
Did you try these? ObjectMemory>>#growThresholdPercent: ObjectMemory>>#bigObjectThreshold: ObjectMemory>>#spaceGrowRate: > 2.) For my fakebts (debian packages here[1]) I write code like this.. > > gst> 1 to: 10000 do: [:unused | [test requireAnyChannel] fork ]. > > now this can easily generate an OOM and cause an abortion.. > > gst> 1 to: 10000 do: [:unused | > [test requireAnyChannel. ObjectMemory compact] fork] > > is 'working' on the other hand. I wonder if there could be a better > solution? In Pharo I think there is a OOM watcher task, I wonder if > one could reserve like three contexts.. and triger a cleaner task > once the memory is running low? OOM is a bad problem indeed. 3 contexts are definitely not enough; a cleaner can allocate memory for BlockClosures too. There is also the mark stack, which is needed to actually make some room after running the cleaner. Can you do some plots of the ObjectMemory statistics after each of the 10000 iterations? Paolo _______________________________________________ help-smalltalk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-smalltalk
