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
signature.asc
Description: OpenPGP digital signature
