RFR: jsr166 jdk9 integration wave 12

Vitaly Davidovich vitalyd at gmail.com
Wed Oct 19 01:33:38 UTC 2016


On Tuesday, October 18, 2016, Martin Buchholz <martinrb at google.com> wrote:

>
>
> On Tue, Oct 18, 2016 at 4:26 PM, Vitaly Davidovich <vitalyd at gmail.com
> <javascript:_e(%7B%7D,'cvml','vitalyd at gmail.com');>> 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


More information about the core-libs-dev mailing list