JDK-8179019 : Correct range checks for command-line options ArraycopySrcPrefetchDistance and ArraycopyDstPrefetchDistance
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-04-20
  • Updated: 2019-09-13
  • Resolved: 2017-04-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10 b21Fixed
Related Reports
Relates :  
JDK-8078554 - Compiler: implement ranges (optionally constraints) for those flags that have them missing
Description
Constrains for ArraycopySrcPrefetchDistance and ArraycopyDstPrefetchDistance XX options were added in the JDK 9 to the hotspot/src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp file.

Accoring to the added constraints the only possible value for ArraycopySrcPrefetchDistance and ArraycopyDstPrefetchDistance options is 0. All other values are rejected.

So, it seems that these options can be deprecated and removed in the future release. Also, corresponding code for these options also can be removed.

zmajo: Instead of deprecating the two options, I'll change the constraints to allow a range for the flags.
Comments
In 2 places (around lines 1020 and 1044) sub() instructions should use O4 register instead of prefetch_count value. Unfortunately for add() instruction after call we need to set O4 again since the called code uses O4: __ set(prefetch_count, O4); __ cmp_and_brx_short(count, O4, Assembler::less, Assembler::pt, L_block_copy); __ sub(count, prefetch_count, count); (this->*copy_loop_func)(from, to, count, count_dec, L_block_copy_prefetch, true, true); __ add(count, prefetch_count, count); // restore count 4095 number comes from limit on number of bit in prefetch instruction: if (ArraycopySrcPrefetchDistance > 0) { __ prefetch(from, ArraycopySrcPrefetchDistance, Assembler::severalReads); } if (ArraycopyDstPrefetchDistance > 0) { __ prefetch(to, ArraycopyDstPrefetchDistance, Assembler::severalWritesAndPossiblyReads); }
21-04-2017
ILW=reduced configurability of VM, rarely experienced issue (users are usually fine with default values for flags), no workaround = LLH = P5
21-04-2017
The upper limit of the range [0, 4095] is not OK, we get a failing assert with -XX:ArraycopySrcPrefetchDistance=4095 (see below). I have to spend more time on figuring out what a proper upper limit would be. # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/opt/jprt/T/P1/112110.zmajo/s/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:396), pid=17201, tid=2 # assert(nbits == 32 || (-(1 << nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range: x=0x0000000000001000, nbits=13 # # JRE version: (10.0) (fastdebug build ) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 10-internal+0-2017-04-21-112110.zmajo.8179019, compiled mode, tiered, compressed oops, g1 gc, solaris-sparc) # Core dump will be written. Default location: /tmp/8179019/core or core.17201 # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -XX:ArraycopySrcPrefetchDistance=4093 -Xcomp Host: sca00bnx, Sparcv9 64 bit 3600 MHz, 16 cores, 32G, Oracle Solaris 11.2 SPARC Time: Fri Apr 21 11:59:14 2017 UTC elapsed time: 0 seconds (0d 0h 0m 0s) --------------- T H R E A D --------------- Current thread (0x00000001001a9000): JavaThread "Unknown thread" [_thread_in_vm, id=2, stack(0xffffffff7d200000,0xffffffff7d300000)] Stack: [0xffffffff7d200000,0xffffffff7d300000], sp=0xffffffff7d2fe5a0, free space=1017k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1eed6ac] void VMError::report_and_die(int,const char*,const char*,void*,Thread*,unsigned char*,void*,void*,const char*,int,unsigned long)+0xc2c V [libjvm.so+0x1eeca0c] void VMError::report_and_die(Thread*,const char*,int,const char*,const char*,void*)+0x3c V [libjvm.so+0xcba698] void report_vm_error(const char*,int,const char*,const char*,...)+0x78 V [libjvm.so+0x6f3dc4] void Assembler::assert_signed_range(long,int)+0x94 V [libjvm.so+0x1d641e0] void StubGenerator::disjoint_copy_core(RegisterImpl*,RegisterImpl*,RegisterImpl*,int,int,void(StubGenerator::*)(RegisterImpl*,RegisterImpl*,RegisterImpl*,int,Label&,bool,bool))+0\ x4d0 V [libjvm.so+0x1d60754] void StubGenerator::copy_16_bytes_forward_with_shift(RegisterImpl*,RegisterImpl*,RegisterImpl*,int,Label&)+0x844 V [libjvm.so+0x1d5bd6c] unsigned char*StubGenerator::generate_disjoint_byte_copy(bool,unsigned char**,const char*)+0xb5c V [libjvm.so+0x1d42acc] void StubGenerator::generate_arraycopy_stubs()+0x3c V [libjvm.so+0x1d16ce4] void StubGenerator_generate(CodeBuffer*,bool)+0x1b4 V [libjvm.so+0x1d6651c] void StubRoutines::initialize2()+0x16c V [libjvm.so+0xf9baa0] int init_globals()+0x1c0 V [libjvm.so+0x1e33578] int Threads::create_vm(JavaVMInitArgs*,bool*)+0x4c8 V [libjvm.so+0x114aca8] int JNI_CreateJavaVM_inner(JavaVM_**,void**,void*)+0x108 C [libjli.so+0x7620] InitializeJVM+0x100 C [libjli.so+0x4d8c] JavaMain+0x5c C [libc.so.1+0xe4af0] _lwp_start+0x8
21-04-2017
It is bug that restriction is 0. Before JDK-8078554 changes the range was [0 <= x < 4096] : - assert(ArraycopySrcPrefetchDistance < 4096, "invalid value"); - if (ArraycopySrcPrefetchDistance >= 4096) - ArraycopySrcPrefetchDistance = 4064; - assert(ArraycopyDstPrefetchDistance < 4096, "invalid value"); - if (ArraycopyDstPrefetchDistance >= 4096) - ArraycopyDstPrefetchDistance = 4064; http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/0300297e7df3#l2.32 [~zmajo] Please, look and file bug to fix it.
20-04-2017