On Aug 6, 2007, at 12:48 AM, Joel Uckelman wrote: > Thus spake Thomas Russ: >> > >> [*] IIRC Java uses a copying garbage collector, which means that the >> heap memory in use is at most half of the memory allocation, to make >> sure there is enough room to copy the live data over when garbage >> collection is triggered. That means that as long as additional >> memory isn't being allocated by Vassal, half of the allocated space >> can be on disk without any performance penalty. > > Huh. I did not know that.
Actually, now that I took some time to look into it, it turns out that the story is more complicated (isn't it always?). Anyway, apparently there are several different algorithms in use in the JVM, one of which is a copying collector like I described above. That is normally used for the newest objects created. The older objects use a compacting, mark-and-sweep algorithm that doesn't require twice the space. That provides a reasonable trade-off between space and time. The impact of that is that with long-surviving objects (which would be the graphics objects in Vassal, since they pretty much never become garbage) will end up in "old object space" and won't have this effect. The upshot is that more than half of the memory can be actively in use. Still, the practical effect is that one can use the virtual memory system to manage this, and as long as there is reasonable locality of reference, then the items that get paged out to disk are the ones not being actively accessed. So that shouldn't have too big an impact on performance. Of course, if you actually NEED access to all of that memory, then the paging will slow down Vassal on systems with less RAM, but the only other alternative is to not have them run at all, so....
