10) We fixed some bugs.
9) Thread local allocation buffer dynamic tuning. (see "A Little Thread Privacy Please")
8) Promotion failure handling was implemented for the low pause collector.
Promotion failure handling is the ability to start a minor collection and
then backout of it if there is not enough space in the tenured generation
to promote all the objects that need to be promoted.
In 5.0 the "young generation guarantee" need not apply for the low pause collector because we implemented promotion failure handling for that collector. The net effect of having promotion failure handling is that more minor collections can be done before a major collection is needed. Since minor collections are typically more efficient than major collections, it's better. The "young generation guarantee" is discussed in the document below.
It was particularly harsh on the low pause collector because the "young generation guarantee" required one contiguous chunk of space in the tenured generation. For the low pause collector that requirement could be difficult to satisfy because the low pause collector does not compact the tenured generation and so is subject to fragmentation.
7) Parallel remark in the low pause collector.
For the low pause collector there are two stop-the-world pauses associated with each collection of the tenured generation: the initial marking pause and the remarking pause. The latter is typically much longer than the former. In 5.0 the remarking is done with multiple threads in order to shorten it.
6) Parallel reference processing in the low pause collector.
For an application that uses Reference objects (see)
extensively, the GC work to process the Reference objects can be noticeable. It's not necessarily worse in the low pause collector than in the
other collects, but it hurts more (because we're trying
to keep the pauses low).
Parallel reference processing is available for the
low pause collector but is not on by default.
Unless there are tons of Reference Objects, doing the reference
processing serially is usually faster. Turn it on with the flag -XX:+ParallelRefProcEnabled
if you make extensive use of Reference Objects (most applications don't).
5) Server class machine defaults.
On server class machines (machines with 2 or more cpus and
2G or more of physical memory) the default
compiler, garbage collector and maximum heap size are different.
Before 5.0 it was
\* -client compiler
\* serial garbage collector
\* 64M maximum heap (on most 32 bit platforms)
With 5.0 the defaults for server class machines are
\* -server compiler
\* throughput garbage collector
\* maximum heap size the lesser of 1/4 of physical memory or 1G
For the smaller machines the defaults did not change.
The intent of this change was to provide better default performance
on large machines that are typically dedicated to running 1 or a
few applications and for which throughput is important. Desktops
interactivity was expected to be more important were excluded from
being server class machines.
for more details.
4) Low pause collector schedules remarking between minor collections.
Recall that the pause due to object remarking is the longer of the two
stop-the-world pauses. Before 5.0 it could happen that a remark pause would occur
immediately after a minor pause. When this back-to-back minor pause and
remark pause occurred it looked like one big fat pause. With 5.0
the remarking is scheduled so as to be about mid way between two minor pauses.
3) Better scheduling of the start of a concurrent low pause collection.
Prior to 5.0 a low pause collector started a collection
based on the rate of allocation
and the amount of free space in the tenured generation. It did the calculation and started
a concurrent collection so as to finish before the tenured generation ran dry. This was good, but there were some end cases that needed
to be recognized. For example, if
the tenured generation had to be expanded in order to support
promotions for a minor collection that just
finished, a concurrent collection was started right away.
Or if the next minor collection might not succeeded because
of lack of free space in
the tenured generation, then a concurrent collection was started. That latter example
wouldn't happen if we could perfectly predict the rate at which the tenured generation
is filling up. We're not perfect. Also a bump in the allocation rate might mess us up.
2) GC ergonomics (See "It's Not Magic" at the start of my blogs)
And the number 1 GC reason for upgrading to 5.0 is
You can tell me what you've found to be a good
reason to upgrade to 5.0 in a comment to this blog.
Don't be shy. And thanks for any responses.