Re: Ranting about JVM's default memory limits...
Andreas Leitgeb wrote:
PS: Wouldn't this also bias the decision towards object re-use and
away from throw-away-and-get-a-new-one? (At least, if some
tenured object has to have a reference on it...)
No. If the tenured object holds a reference to an object, then it
stays alive as long as that reference is held. If it needs to hold
that reference for a long time, then the referenced object will
eventually get tenure anyway. If it doesn't need to hold it for long,
then the reference should be released to allow GC of the unneeded
object. It's unfortunate if that causes a tenured-to-nursery
reference, but that's better than distorting the logic of your program
because you're trying to second-guess the collector.
It is enough to idiomatically use short-lived stack/local references
to short-lived objects, like creating a new object inside a loop for
each iteration instead of a single one before the loop that is re-used
each iteration. Don't use instance variables for that type of
throwaway, but go right ahead and assign to instance variables where
it makes sense to do so for intrinsic reasons. Typically such
assignments will tend to happen near the beginning of the referring
object's life, and tend to last as long as the referring object does.
Thus the referenced and the referrer will tend to have similar
lifespans.
For the most part the logic of the program will keep short-lived
objects referenced mostly by other short-lived objects or from local
variables. You won't eliminate every possible unfortunate reference,
perhaps, but you probably will get most of them that way.
PPS: Do stackframes also "qualify" as objects in this context?
As I understand what a stack frame is, the question doesn't make sense
- a stack frame simply is not an object, and does not get garbage-
collected. In what fashion do you contemplate viewing a "stack frame"
as an object, and what do you mean by a "stack frame" in this context?
--
Lew