Need to digest the rc-immix stuff. The RC-immix paper does not report pause times, which is unfortunate. The > URC paper reports typical pause times of 70ms for some benchmarks when > using a 4 MByte nursery. This is uncomfortably high. For calibration, > modern game frame generation latencies are one frame per 16ms, and trending > toward 8 ms. > > I saw that ,, my thoughts were - As per table 5 Setting a 30ms "time cap" instead of the default 60 showed typical pause of 48 . And the cap was exceeded due to Nursery sweep. This time cap feature is intersting. - it was superior to pure RC without cycle detection ( and obviously GCs) and hence very likely RC-Immix - It was HW from over 10 years ago when a 60 ms 1 frame pause was acceptable .. its not on modern hw. - The pause in the paper is independent of heap size, It relates to Nursery size. This is very important. It maybe with a massive heap the time increases but the pauses in the paper were due to the Nursery sweep. Pause vs heap size was not explored in detail , with the higher cap larger heaps gave higher pauses up to about the cap value . Its hard to tell but with the lower cap in place the one that exceeded the cap the most had a small heap . - it did exceed the adjustable time cap due to nursery collection . There are way better Nursery sweep techniques for pauses since then as eg by modern cocurent GC techniques or evern simple using more memory and swapping nuseries , sweeping the nursery in the background and using a barrier while it is active. As long as the nursery is big enough to cover new allocations durring the sweep it should massively reduce pauses. - malloc in 2003 probably has worse than 60 ms pause , i could not determine if the pause times were global ( there test machine was non multi core) but i see no reasons why it needs to be. If it does you can run a small nursery as above for very small global pauses at the cost of performance ( and higher allocating thread pauses) for maloc like behaviour.
So you can trade of this time either pause time vs efficiency or pausetime vs complexity . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
