Impact of code difference in Collection#contains() worth improving?

Ulf Zibis Ulf.Zibis at
Sat Aug 30 14:17:40 UTC 2014

Am 30.08.2014 um 01:33 schrieb John Rose:
> On Aug 29, 2014, at 1:05 PM, Ulf Zibis <Ulf.Zibis at <mailto:Ulf.Zibis at>> wrote:
>> Thanks for explaining this, but a very little nit: the immediate (I.e. -1) uses additional 32/64 
>> bits in code which must be loaded from memory and wastes space in CPU cache or am I wrong? This 
>> could be saved with >= 0.
> I have to say you're more wrong than right about this.  Optimizers routinely change the form of 
> constants.  For example, a constant 0 will often show up as something like "xor eax,eax", not a 
> 32-bit literal zero that loads from somewhere in memory.  A comparison of the form "x > -1" will 
> be freely changed to "x >= 0" and back again; the latter form may (or may not, depending on chip 
> version) transform to "test eax", with no "-1" or "0" in sight.

1. Thanks for the hint about "x > -1" ===> "x >= 0". But I'm afraid this would apply on the "x != 
-1" case we are discussing here.
2. Are you really sure this optimization is always implemented, as following bug is still open:
JDK-6984886 : Transform comparisons against odd border to even border 


More information about the core-libs-dev mailing list