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 .... https://bugs.openjdk.java.net/browse/JDK-6445664 Eliminate remaining performance penalty for using assert On Fri, Aug 29, 2014 at 4:33 PM, John Rose <john.r.r...@oracle.com> wrote: > On Aug 29, 2014, at 1:05 PM, Ulf Zibis <ulf.zi...@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. > > 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
