🚀 go-pugleaf

After going off on an tangent in another newsgroup, I got to thinking
about the problem with memory heap compaction.  Currently, the JVM does
not return compacted memory back to the OS.  That means an application
that runs 24x7 will continually grab more memory until the OS halts the
JVM with an error.  (This has been reported in NT, SunOS and Linux.)
Until JavaSoft fixes this (bug fix planned for 1.2beta4), we have to
very meticulously resuse objects for 24x7 applications.  I'd like to
explore the best way of implement a recycler class.  I already have
something in my application but it's very ugly and I prefer to rip it
out and replace it with code that's more elegant and flexible.

My initial idea is to base the recycler class on a static vector.  Use
the vector like a stack -- objects no longer needed at added to the end
of the vector.  When creating objects, instead of using "new" to
instantiate objects, pop an object off and populate (or reset) the data
fields.  The devil, of course, is in the details.  What's your take on
where the responsibility to maintain these recycling stacks belong.
Should each class implementing the recycler interface maintain a
separate stack?  Or should there be a "super-recycler" that can maintain
stacks for everybody?

BTW, is there anyway to get the current date/time without creating a new
object?  This would allow me to recycle Date objects when I need current
time.