On Tuesday 22 May 2012 13:04:24 Andy Ross wrote: > On 05/20/2012 11:37 AM, Stefan Seifert wrote: > > Generational garbage collection is not that difficult. When you have a > > working mark& sweep GC, extending it to be generational is rather > > straight forward and can greatly reduce GC runtime > > Runtime, yes, but not latency bounds. You still have to touch the > whole heap eventually. > > But you're right: allocating objects into generations and only > mark/reaping from the most recent one on most iterations is a > straightforward optimization and will definitely make things faster.
Maybe even simpler: run the GC in a separate thread. Threaded GC usually is quite tricky but in this case it may not be that much of a problem. Is there any time during processing a new frame when no Nasal is run but something else which is time consuming? This could be the perfect point to hide the GC's latency. FG does not use multiple cores that well so there should be at least one core which is bored and might tend to the garbage instead while the main thread is busy rendering pretty graphics. A single condition var might be enough to ensure that the GC is not running at the same time as Nasal execution. In my naive imagingation, this sounds like a single evening experiment ;) Stefan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
