[10] RFR(S): JDK-8184943: AARCH64: Intrinsify hasNegatives

White, Derek Derek.White at cavium.com
Fri Jul 21 14:05:49 UTC 2017

Hi Andrew,

If this is a problem, there might be a problem in copy_memory (stubGenerator_aarch64.cpp) as well, where we may read past an array. 

I went looking for see if there's some padding at the end of a heap region that we were counting on, but didn't find any yet.

 - Derek

> -----Original Message-----
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-
> bounces at openjdk.java.net] On Behalf Of Andrew Haley
> Sent: Friday, July 21, 2017 4:22 AM
> To: Dmitrij Pochepko <dmitrij.pochepko at bell-sw.com>
> Cc: hotspot-compiler-dev at openjdk.java.net; aarch64-port-
> dev at openjdk.java.net
> Subject: Re: [10] RFR(S): JDK-8184943: AARCH64: Intrinsify hasNegatives
> On 20/07/17 19:27, Dmitrij Pochepko wrote:
> > Btw: I've also considered such unconditional 8-bytes load at start,
> > but abandoned this idea since I wasn't sure if it's safe. Say, array
> > is allocated at the border of allocated region(so, last array byte ==
> > last allocated region byte). Then hasNegatives is called with offset
> > == array_length - 1 and len = 1 just to check last byte, so, then
> > 8-byte load is issued at this address?
> It's certainly possible.  We can't read an address beyond our byte array if
> there is any possibility that we're at the end of a page, because we might hit
> a segfault.  We could test for that.
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the hotspot-compiler-dev mailing list