Poor G1 performance when no collection possible
Benedict Elliott Smith
lists at laerad.com
Tue Apr 19 12:31:39 PDT 2011
I've been comparing the GC overhead of a couple of algorithms under
different GC settings, and I have found what seems to be fairly negative
behaviour from G1, which I would like to understand if possible.
Firstly, if I allocate a huge number of objects and guarantee that none of
them can be reclaimed, G1 will still spend a huge amount of energy (around
about 50% of the real time of the test, more if I parallelise the test)
attempting to collect nothing at all. This is the main head scratcher; in
fact, many of the collections indicate negative work being achieved
(e.g. [GC pause (young) 1221M->1222M(3044M), 0.1388195 secs]).
The second issue is that the only difference between the two algorithms wrt
garbage collection, when running the test serially, is that one of them
jumbles up new and old object pointers, whereas the other doesn't. This
seems to have a really drastic effect on the performance of G1, as the break
down below shows. The first two lines of each section are the time spent
doing non-GC and GC work respectively; the second two lines indicate the
amount of space reclaimed in total by all of the GCs combined ("orig
samples" indicates the number of distinct GCs performed). These are
relatively brief tests, but after giving everything a couple of runs through
to warm up, and the behaviour I'm seeing is very consistent across repeats.
Test1 EXCL. GC (ms): total=43982, avg=21991, stdev=314
Test1 GC (ms): total=42322, avg=21161, stdev=299
Test1 partial (K): total=1000, avg=500, stdev=500, repeats=2 (orig
Test1 young (K): total=-33000, avg=-16500, stdev=3500, repeats=2
Test2 EXCL. GC (ms): total=43838, avg=21919, stdev=133
Test2 GC (ms): total=49132, avg=12283, stdev=8880
Test2 partial (K): total=6000, avg=3000, stdev=3000, repeats=2 (orig
Test2 young (K): total=-20000, avg=-10000, stdev=1000, repeats=2
So, would you say this behaviour is expected?
I have uploaded the verbose gc log
a separate run, in case that offers any useful information.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-dev