Le 03/03/2017 à 17:22, Eliot Miranda a écrit :
It is important to realize that scavenge time depends on the amount of objects that survive, not on the size of new space. So increasing the size of new space will only cause longer pause times when an application is growing the heap, which is the case when Moose reads models. But if an application is following the standard pattern of creating many objects, most of which are collected, then a large eden should not cause noticeably longer pause times. This is because a scavenge copies the surviving objects from eden and past space into future space, overflowing into old space, tracing reachable objects only. So only if lots of objects survive does scavenging touch lots of data. If only a few objects survive the scavenger touches (copies) only those objects.
The VM collects times so you could do some experiments and measure the average scavenge time for the Moose application during its growth phase and then during its normal phase. I think you'll find that the large new space is not an issue for normal usage.
There is another variable that can affect pause times and that is the number of stack pages. The roots of a scavenging collection are the remembered table and the stack zone. So the larger the stack zone, the more time is spent scanning the stack looking for references to objects in new space. This is a difficult trade off. If one has lots of Smalltalk processes in one's application with lots of context switchers between them (this is the threading benchmark) then one wants lots of stack pages, because otherwise a process switch may involve evicting some contexts from a stack page in order to make room for the top context of a newly runnable process. But the more stack pages one uses the slower scavenging becomes.
Cog's default used to be very high (160 pages IIRC) which was determined at Qwaq, whose Teatime application uses lots of futures. I've reduced the default to 50 but it is an important variable to play with.
However for UI applications (typically the IDE), the scavenge pauses may become significant enough to be noticed by the programmer. Maybe not at 12Mb, but certainly at 64Mb.
I doubt this very much (because of the argument above). Remember that the scavenger is a garbage collector specifically designed to work well with systems like Smalltalk where lots of intermediate objects are created when computing results. Scavenging doesn't touch objects that are reclaimed, only objects that survive. So this works well. I think you'll find that GUI applications fit this pattern very much and so a large new sad should not present a problem.
-- _,,,^..^,,,_ best, Eliot
Awesome! I look forward finding the time to test all this :) -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France