[aarch64-port-dev ] aarch64: Fix a bug in TestOptionsWithRanges of hotspot

[Stuart Monteith]

>From my reading of this - BlockZeroingLowLimit is the N bytes that dc zva
would write in a single operation - zva_length.
I can see a case for the minimum of being zva_length, but the maximum
shouldn't have a limit really - and nothing as small as you are
suggesting.  That the cmp immediate limit is smaller than we like is
incidental to the actual limit we'd be aiming for. Say, for example, there
was only an advantage on some machines/workloads above 2 MB.

Can you look into reworking the "cmp" call to something more permissive?

Thanks,

   Stuart


On 28 June 2016 at 09:40, Yang Zhang <yang.zhang at linaro.org> wrote:

> In file src/cpu/aarch64/vm/stubGenerator_aarch64.cpp:2350,
> BlockZeroingLowLimit is used as follows:
> __ cmp(cnt_words, BlockZeroingLowLimit >> 3);
>
> On aarch64 platform, the immediate in cmp instruction has 12
> significant bits which could be 0xXXX or 0xXXX000. The immediate is
> calculated by BlockZeroingLowLimit >> 3. So BlockZeroingLowLimit has
> 15 significant bits. It's low limit, and a vary large value isn't
> meaningful. So the range of BlockZeroingLowLimit should be [1, 2^15 -
> 1].
>
> On 28 June 2016 at 16:16, Andrew Haley <aph at redhat.com> wrote:
> > On 28/06/16 05:09, Yang Zhang wrote:
> >> Could someone please help to review and process attached patch for
> fixing
> >> an issue about BlockZeroingLowLimit in hotspot openjdk9 aarch64?
> >>
> >> This issue is exposed by a test failure in hotspot jtreg openjdk9 for
> >> aarch64
> >>
> >> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
> >>
> >> It is caused by improper range of BlockZeroingLowLimit.
> >
> > Surely this is just papering over the real bug.
> >
> > Andrew.
> >
>