BUT, during the turn, while the data is stil relevant, a minor collection can occur, which could result in the data being placed in the tenured gen. And, well, if that's the case, on the next turn, the app can easily run out of free memory, start full GC and time out. It still holds true for the CMS collector, as it may not have enough time to free enough memory in the tenured gen (since the new data is generated faster that the old data is collected).
So, it would be really great if the java contestants were allowed to specify SOME (not all, obviously) options to the garbage collector, especially the distribution of memory among memory pools. In my case, the issue is easily solved by reducing the size for the tenured gen in favor of the eden space and the survivor space.
Another option is to clear all the references to the old data at the end of the turn, explicitly call System.gc() and, hoping that it would help, wait until either the memory seems to be freed or the turn is about to end, and only then send the 'go' line.
Anyways, the situation is more sad than amusing, as this is a great example of the .
Statistics: Posted by gvsmirnov — Thu Nov 03, 2011 11:20 pm