RFR: jsr166 jdk9 integration wave 13

Martin Buchholz martinrb at google.com
Wed Dec 14 17:07:42 UTC 2016


Yeah, I'm not happy with Arrays.rangeCheck.  It's hotspot's job to do (and
optimize away) array bounds checks, and provide informative exception
messages when a check fails.

On at least one occasion I wanted to have fromIndex > toIndex be a no-op.

The exceptions on Arrays.fill are all spec'ed out - I'm not hoping to be
able to change them.

On Wed, Dec 14, 2016 at 8:30 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> On 13 Dec 2016, at 19:37, Martin Buchholz <martinrb at google.com> wrote:
>
> Hotspot appears to have support for the array filling code pattern, but
> Arrays.fill itself is not intrinsified.
>
>
> Yes. I suspect in general it should be ok here. FWIW i still would like to
> make it an explicit intrinsic and improve the code generation.
>
>
>   There are bounds checks which hotspot may not be able to elide.
>
>
> Ah, yes, its the range fill that performs explicit checks (also with the
> IAE vs IOOBE, we are inconsistent in the handling of this in other places).
>
> If this is an issue I think we could probably improve this, since the loop
> anyway has to check the bounds, so perhaps could branch on >=, then branch
> on >.
>
> Paul.
>
> For almost all software, Arrays.fill is good enough, but core library
> collections are an exception.  Also, we introduce other little abstractions
> like shiftTailOverGap and circularClear.  Another possibility is to
> introduce our own tiny helper method without checks
>
> nullOutSlice(Object[] a, int from, int to)
>
> On Tue, Dec 13, 2016 at 5:26 PM, Paul Sandoz <paul.sandoz at oracle.com>
> wrote:
>
>>
>> One general question: why did you replace Arrays.fill with an explicit
>> loop in many cases?
>>
>>
>


More information about the core-libs-dev mailing list