Impact of code difference in Collection#contains() worth improving?
Ulf.Zibis at CoSoCo.de
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 cosoco.de <mailto:Ulf.Zibis at cosoco.de>> 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