[concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number

Dawid Kurzyniec dawidk@mathcs.emory.edu
Tue, 13 Jan 2004 22:38:25 -0500


> -----Original Message-----
> From: concurrency-interest-admin@cs.oswego.edu 
> [mailto:concurrency-interest-admin@cs.oswego.edu] On Behalf 
> Of Gregg Wonderly
> Sent: Tuesday, January 13, 2004 8:08 PM
> To: Dawid Kurzyniec
> Cc: concurrency-interest@altair.cs.oswego.edu
> Subject: Re: [concurrency-interest] Re: AtomicInteger and 
> AtomicLong should implement Number
> 
> 
> I have existing code that has the following logic in it.
> 
> 	if( NumberImpl1.equals(NumberImpl2) ) {
> 		...
> 	}

If you have code like that, which does arithmetic on number wrappers
rather than on flat primitives, you can't seriously claim that this
particular application is concerned about memory allocation overhead
caused by the wrappers. Apparently, the authors of that code didn't
think of it as a big deal. If so, the use of get() should be no problem
here even if you have to depend on autoboxing. If they were wrong, the
problem lies in their code and it should not be cured by bending the
general-purpose concurrency API.

BTW. I believe that allocation of primitive wrappers is extremely well
optimized in Java, since those are final classes (no virtual method
table, size precisely known) and since it is such a common pattern. I
wouldn't be surprised if in fact most short-lived usages of numeric
wrappers were optimized by JIT to the point where there was no heap
memory allocation whatsoever. Does somebody know if "autoboxing" JSR
group have some actual benchmark results?...

Regards,
Dawid