JDK-8189208 : Cleanup ancient argument processing code
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-10-12
  • Updated: 2019-08-15
  • Resolved: 2019-05-09
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 13
13 b21Fixed
Related Reports
Relates :  
Relates :  
Description
Noticed in a code review.

arguments.cpp:

3489   // Change the default value for flags  which have different default values
3490   // when working with older JDKs.
3491 #ifdef LINUX
3492  if (JDK_Version::current().compare_major(6) <= 0 &&
3493       FLAG_IS_DEFAULT(UseLinuxPosixThreadCPUClocks)) {
3494     FLAG_SET_DEFAULT(UseLinuxPosixThreadCPUClocks, false);
3495   }
3496 #endif // LINUX

the above is for Java 6 and below.

Should check if there is anything else in there like that.
Comments
Some of the checks may pertain to classfile versions, in which case they are fine and necessary. It's only API related checks that are irrelevant, Comments like: ./share/classfile/vmSymbols.hpp: /* Support for annotations (JDK 1.5 and above) */ are also fine. The issue is really only using JDK_Version::current().compare* (of which there seems to be this one case left) or the JDK_Version supports_thread_park_blocker related logic - which can all be stripped out.
30-04-2019

Grepping for : "JDK1." "JDK 1." "JAVA_1" reveals lots of possible targets?
31-01-2019

Found this: // Following function has been added to support HotSparc's libjvm.so running // under Solaris production JDK 1.2.2 / 1.3.0. These came from // src/solaris/hpi/native_threads in the EVM codebase. // // NOTE: This is no longer needed in the 1.3.1 and 1.4 production release // libraries and should thus be removed. We will leave it behind for a while // until we no longer want to able to run on top of 1.3.0 Solaris production // JDK. See 4341971. #define STACK_SLACK 0x800 extern "C" { intptr_t sysThreadAvailableStackWithSlack() { stack_t st; intptr_t retval, stack_top; retval = thr_stksegment(&st); assert(retval == 0, "incorrect return value from thr_stksegment"); assert((address)&st < (address)st.ss_sp, "Invalid stack base returned"); assert((address)&st > (address)st.ss_sp-st.ss_size, "Invalid stack size returned"); stack_top=(intptr_t)st.ss_sp-st.ss_size; return ((intptr_t)&stack_top - stack_top - STACK_SLACK); } } Linking JDK-4341971
31-01-2019

Use of JDK_Version::current().supports_thread_park_blocker() seems irrelevant. In general any JDK_Version code that exists to check whether we are running on anything but the latest version, is now irrelevant.
30-07-2018