Lew said:
Other possibilities are references from long-lived objects to short-
lived ones, and intentional retention of objects in the mistaken
belief that it will reduce GC overhead.
The garbage collector used to be very different.
Old Java garbage collectors like mark-sweep had to do work in proportion
to the number of dead objects. So to make code run fast you reused
objects and avoided discarding too many.
The relatively new generational garbage collector has to do work in
proportion to the number of surviving objects instead. So to make code
run fast you now should discard objects rather than retain them.
GC optimization has basically been turned 180 degrees and stood up on
its head by this. The advice to get the fastest GC performance now is
diametrically opposite what was best with the older GC.
If Mark is working with a Java project with very many tree-rings in it,
it's quite likely the thing was coded exactly as horribly as possible
from the stand-point of GC optimization, because of GC-optimization.
Unfortunately, making it run fast with the newer GC means a lot of work
or even a total rewrite of big chunks of it in that case. On the plus
side, the results will be well worth it, making everything far faster
than the old code used with the older GC. And it's very unlikely that
the next big revolution in GC will flip everything over again, so the
new code will be future-proofed in one respect that the old code
(obviously) wasn't.
Another good reason is that treating most objects as disposable can
greatly simplify a lot of the logic, getting rid of pools and other
scaffolding and allowing some of them to be made immutable, which lets
you get rid of setters and possibly a lot of other code. Code that had
to be maintained, and might contain bugs, as well as was bloating up the
size of the running image and the jar files, bloating up the
documentation, and cluttering up the IDE's method listing and code view.
You can also afford to make classes that encapsulate a few primitives
where you might have once just used the primitives directly to cut down
on object creation. To use a worn-out old example, you can get rid of
all those xs and ys worked on in tandem and use Point2D or Complex or
whatever fits the situation without all those used-up Point2Ds or
Complexes gumming up the garbage collector the way they would have, five
or ten years ago. The code might get more readable, simpler, and less
error-prone.
Or you might just end up wishing for operator overloading to be in Java
7.
- jenny