There is a problem with predictions in conjunction with adaptive gc thread sizing: the number of gc threads is only determined by the heap size, not the pause time goal.
This seems to be able interfere with keeping the pause time goal.

Gcbasher (running only with -Xmx512m and a small pause time goal like 15ms) shows the following behavior:

- remark pause uncommits a significant amount of memory, decreasing heap size (the number of gc threads for the next gcs has been X at this time)
- mixed gc keeps pause time (using X-1 gc threads)
- the two next normal young gcs are way over pause time (like 20-25ms); always the first normal young gc takes less time than the second. The reason seems to be because it uses X-2/X-3 gc threads;
- the young gcs make the heap expand; so the next 6 or 7 normal young gcs keep pause time well again, using X gc threads again
- cycle repeats

I.e. the prediction gets badly influenced by the dynamic thread sizing.

This issue is day one, however may show up more often by making dynamic gc thread sizing default and uncommitting memory at Remark.

Can be fixed by disabling dynamic gc thread sizing (which is also disabled when just specifying ParallelGCThreads on the command line).