On Tuesday, October 18, 2016, Martin Buchholz <[email protected]> wrote:
> > > On Tue, Oct 18, 2016 at 4:26 PM, Vitaly Davidovich <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> "jsr166 style" - makes it easy on javac and the JIT, if not for humans. >>> >> In some of the cases here, I'd consider it a significant JIT failure if >> the "jsr166 style" makes a difference (I'm not sure how this makes a >> difference to javac - did you mean interpreter?). Is this jsr style a >> carryover from long ago? Maybe it needs to be reconsidered. The code >> clarity isn't terrible, but it would be unfortunate to do this in simple >> cases where the compiler ought to handle it just fine - does it not? >> > > I consider it a significant failure that > > 1. JDK-6445664 <https://bugs.openjdk.java.net/browse/JDK-6445664> > > Eliminate remaining performance penalty for using assert > > still hasn't been fixed. > Indeed - the whole inlining based on simple bytecode size is a big problem (I've brought this up in various contexts several times on the compiler list, but this is a known issue). But, some of the methods using the jsr style look to already be >35 bytes. I've seen this style in other places in the JDK where the method is definitely above 35. My thinking was this must be some manual attempt to force the compiler to put the value in a register or stack slot, for fear that it wouldn't do it on its own because it can't prove it's safe, rather than inlining. Anyway, the style is odd, perhaps outdated to some degree, but not that big of a deal in the grand scheme of things (IMO). I mostly wanted to know of impact on ArrayDeque performance due to the code restructuring. -- Sent from my phone
