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

Martin Buchholz martinrb at
Sat Aug 30 00:27:45 UTC 2014

Hi John,

I agree that the benefit is very small, but I am coming at this from source
code consistency and bytecode size (not jitted code performance), and I
think bytecode size is at least one of the problems with assert.


I filed that bug long ago, but no action yet ....
Eliminate remaining performance penalty for using assert

On Fri, Aug 29, 2014 at 4:33 PM, John Rose <john.r.rose at> wrote:

> On Aug 29, 2014, at 1:05 PM, Ulf Zibis <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.
> Also, even if you can (on some sunny Friday) detect 32 or more one-bits in
> an instruction stream, it does not follow that tweaking your source code to
> make them disappear will prevent them from reappearing (in the dark of the
> next solstice or the next update release of the JVM).  And this won't be a
> bug, because data loads from instruction cache are extremely cheap, since
> in most present chips they are pipelined well ahead of any use.
> Changing source code on based on the difference between 0 and -1 is almost
> as pointless as removing whitespace and comments, or swapping "a+b" to
> "b+a", hoping somehow to improve efficiency.  Sure, it might happen if you
> are lucky but because it's luck, your luck will change.
> I hate to say it, but (as a different example) removing "asserts" is much
> more likely to improve performance than shuffling constant spellings.  And
> this is because of a more important bug in the JIT, where inline decisions
> wrongly take into account the presence of inactive asserts.
> I'm not trying to evade the present subject, but in the grand scheme of
> things this email thread is shuffling equivalent chunks of furniture, which
> the JIT is going to reshuffle behind your back anyway.
> If you really have a measurable performance problem (as with asserts),
> file a bug against the JIT rather than trying to control code shape by
> making semantically null changes to source code.
> — John

More information about the core-libs-dev mailing list