To potentially control priority of the VMThread we have the flag:

product(int, VMThreadPriority, -1,                                        \
          "The native priority at which the VM thread should run "          \
          "(-1 means no change)")                                           \
          range(-1, 127)  

which gives the user-defined priority range as 0-127.

This gets used as follows to set the thread's native OS priority:

  int prio = (VMThreadPriority == -1)
    ? os::java_to_os_priority[NearMaxPriority]
    : VMThreadPriority;
  os::set_native_priority( this, prio );

Naturally set_native_priority is OS specific and each OS has its own notion of meaningful priority values:

- Windows

Normally available values are -15, -2, -1, 0, 1, 2, 15, though the interpretation depends on the scheduling class. For realtime priority class it can also be -7, -6, -5, -4, -3, 3, 4, 5, or 6

So 0-127 has limited use here.

- AIX

Beginning with AIX 5.3, you can change the priority of a thread when you set its scheduling policy to SCHED_OTHER. The legal values that can be passed to the pthread_setschedparam subroutine are from 40 to 80, however, only privileged users can set a priority greater than 60. A priority in the range of 1 to 39 provides the same priority as that of 40, and a priority in the range of 81 to 127 provides the same priority as that of 80.

So 0-127 works here

- macOS

Uses pthread_setschedparam but I could find no specification for the allowed priority values.

- Linux

Uses the setpriority method  which is actually defined to set the priority (actually "nice level") of processes not threads. However we have this comment:

// The following code actually changes the niceness of kernel-thread/LWP. It
// has an assumption that setpriority() only modifies one kernel-thread/LWP,
// not the entire user process, and user level threads are 1:1 mapped to kernel
// threads. It has always been the case, but could change in the future.

Even so the range for the nice level is -20 to 19, with zero as normal and the lower value having higher priority. Consequently the range 0-127 is useless for increasing the priority!

Just as a further note, on all systems except Windows, this scheduling control only comes in to play if the user sets -XX:ThreadPriorityPolicy=1, which typically requires superuser capabilities, or specific security permissions (e.g. SYS_CAP_NICE on Linux).

We also have a bunch of flags to allow individual control of the mapping from Java thread priority (1-10) to OS priority e.g.

  product(int, JavaPriority1_To_OSPriority, -1,                             \
          "Map Java priorities to OS priorities")                           \
          range(-1, 127) 

So again this 0-127 range. Interestingly the compiler thread priority control  has:

  product(int, CompilerThreadPriority, -1,                                  \
          "The native priority at which compiler threads should run "       \
          "(-1 means no change)")                                           \
          range(min_jint, max_jint)                                         \

so you have to know what the OS expects but can at least set whatever value is appropriate. Though because -1 means "do nothing" you can't actually set a native priority of -1.

The problematic ranges were introduced with:

JDK-8078556: Runtime: implement ranges (optionally constraints) for those flags that have them missing
    
part of JEP 245: implement ranges and constraints for runtime flags.

In the original design the range for these flags was defined as -1 - max_int but by the time it was put up for review they had changed to -1 - 127 with a general comment:

"For the rest of the flags, I looked at the existing code that was using them and also did local tests"

The CompilerThreadPriority was set separately by JDK-8078554.

As shown above the range -1 - 127 is not appropriate, and I propose to match what the compiler code does and allow  min_jint - max_jint (and keep the existing behaviour that you can't set an actual priority of -1).