On Wed, Apr 11, 2012 at 12:53 AM, Bennie Kloosteman <[email protected]> wrote: > > On Wed, Apr 11, 2012 at 2:00 AM, Pal-Kristian Engstad > <[email protected]> wrote: >> >> On 4/10/2012 10:09 AM, Jonathan S. Shapiro wrote: >> >> >> So I agree that the behavior you describe exists, but I do not agree that >> it is any sort of impediment to use. The occasional, rare, 20ms pause in an >> application like this just isn't a big deal >> >> >> That depends on the application. Games, as an example, would never >> tolerate a 20 msec pause. The application has to produce images at 30 frames >> per second, or sometimes at 60 frames per second. In a 30 FPS game, you have >> 1,000 [msec] / 30 [frames] = 33.33.. [msec/frame] to respond to user input, >> perform game logic, prepare rendering information and then produce an image. >> As you can clearly see, 20 msec is *huge*, it is 60% of a frame! >> >> I would think that a lot of real-time and soft real-time systems would >> have similar reasons to abandon any system that paused the program for such >> a long period of time. >> > > 3D is the hardest GC case because > 1) It uses a very large activee 1G heap ( and GC times for 1+G heaps are > not pretty) > 2) It is bound to HW device , to which many parts of the Heap communicate
It's usually not nearly as bad as a general 1G heap, since most of the memory should be in the form of large blocks of binary data which don't need to be scanned for pointers. Geoffrey _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
