So, caching numbers will "create more garbage", even if there is a cache
removal mechanism (like WeakHashMap) that allows the garbage collector
to remove Objects when they are not being referenced anymore?

I had always assumed that reusing the same instance of an Object twice
is less costly than creating and destroying an instance twice.

If your statement is correct, then why does Java keep an internal cache
of allocated Strings?


On Tue, 2003-03-11 at 12:59, Juozas Baliuka wrote:
> 
> It will not increase performance, cache will create more grabage itself.
> 
> ----- Original Message ----- 
> From: "grumpoxl" <[EMAIL PROTECTED]>
> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
> Sent: Tuesday, March 11, 2003 9:44 AM
> Subject: [lang] Pooled and mutable numbers.
> 
> 
> > Is there any interest in:
> > 
> > 1) A mechanism for pooling Integers, Floats, Doubles, etc. as they are
> > created, to conserve memory.  For example, instead of having:
> > 
> > new Integer(1) 
> > 
> > scattered throughout the code, there could be a NumberPool class which
> > would allow:
> > 
> > NumberFactory.createInteger(1)
> > 
> > the values would be cached, and could use a WeakHashMap or something
> > similar to manage the cache.
> > 
> > 2) Mutable versions of these same Objects.  There could be an interface
> > named Mutable with a setValue(Object) method, which could have
> > extensions for MutableInteger, MutableFloat, and so on.  I saw something
> > like this in JBoss and thought it seemed like an interesting idea.
> > 
> > Java already has some type of internal pooling for Strings, I think that
> > this type of pooling can be equally useful and may improve performance. 
> > Any thoughts?
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to