JDK-8142340 : Compiler: there are still un-implemented flags
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2015-11-09
  • Updated: 2015-11-23
  • Resolved: 2015-11-23
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 9
9Resolved
Related Reports
Relates :  
JDK-8143616 - Cleanup: Remove unused PrintNMethodsAtLevel flag
Relates :  
JDK-8143616 - Cleanup: Remove unused PrintNMethodsAtLevel flag
Relates :  
JDK-8141641 - Runtime: implement range for ErrorLogTimeout
Relates :  
JDK-8078554 - Compiler: implement ranges (optionally constraints) for those flags that have them missing
Description
jdk_java -XX:+PrintFlagsRanges -version | grep "\[  "  still shows un-implemnted ranges:

COMPILER intx AllocatePrefetchDistance [ ... ] {product} 
COMPILER intx AllocatePrefetchInstr [ ... ] {product} 
COMPILER intx AllocatePrefetchStepSize [ ... ] {product} 
COMPILER intx CompileThreshold [ ... ] {pd product} 
COMPILER intx CompilerThreadPriority [ ... ] {product} 
COMPILER intx InteriorEntryAlignment [ ... ] {C2 pd product} 
COMPILER intx NodeLimitFudgeFactor [ ... ] {C2 product} 
COMPILER intx OnStackReplacePercentage [ ... ] {pd product} 
COMPILER intx OptoLoopAlignment [ ... ] {pd product} 
COMPILER intx PrintNMethodsAtLevel [ ... ] {diagnostic} 
COMPILER uintx TypeProfileLevel [ ... ] {pd product}
Comments
The practical requirement of this enhancement is to remove the currently unused PrintNMethodsAtLevel flag. To make the reviewing process more straightforward for persons not involved in this issue from the beginning, I address the removal of the PrintNMethodsAtLevel flag in a separate issue, JDK-8143616, and will close the current issue as "Not an issue".
23-11-2015
Hi Dmitry, thank you for the investigation and for publishing the results! Best regards, Zoltan
13-11-2015
Hi Zoltan, I ran test similar to the test used for options with ranges on all platforms and currently all seems fine. Test use following values: min_for_type, max_for_type, -1(for signed types), 0, 1, 2147483648(if fits in type), 4294967296(if fits in type)
12-11-2015
Gerard suggested in a private email: "If a flag has a constraint, then the range can be omitted as long as the implicit MIN and MAX for that values type works (ie. no crashes, though VM exit with an error code is permitted as long as it doesn't produce a crash log) " All 8 flags listed in Dmitry's comments have constraints defined. Therefore, I tested the VM with "implicit" min/max values assigned to each flag. Here are the results: intx AllocatePrefetchDistance: VM works fine with both -922337203685477580 and 9223372036854775807 -- OK intx AllocatePrefetchInstr: -9223372036854775808 causes VM exit w/ error code, 9223372036854775807 causes VM exit w/ error code -- OK intx CompileThreshold: same as above intx InteriorEntryAlignment: same as above intx NodeLimitFudgeFactor: same as above intx OnStackReplacePercentage: same as above PrintNMethodsAtLevel: not used by the VM, so it can be removed OK uintx TypeProfileLevel: 0 is valid value, 18446744073709551615 causes VM exit w/ error code -- OK Therefore, the fix for this issue currently is: diff --git a/src/share/vm/runtime/globals.hpp b/src/share/vm/runtime/globals.hpp --- a/src/share/vm/runtime/globals.hpp +++ b/src/share/vm/runtime/globals.hpp @@ -1110,9 +1110,6 @@ diagnostic(bool, PrintNMethods, false, \ "Print assembly code for nmethods when generated") \ \ - diagnostic(intx, PrintNMethodsAtLevel, -1, \ - "Only print code for nmethods at the given compilation level") \ - \ diagnostic(bool, PrintNativeNMethods, false, \ "Print assembly code for native nmethods when generated") \ \ The tests mentioned above were performed on on a linux_x64 machine. Before pushing the fix, it would be great to check the ranges on other architectures as well. It would be nice if that could be done automatically (to save developer time). I'm not sure how flags are tested for which a constraint but not a range is defined (i.e., if Gerard's suggestion from above is already implemented). Could you please notify me if/when automatic testing of these flags is available/turned on so that I can test and then push the fix?
12-11-2015
Ranges for AllocatePrefetchStepSize, CompilerThreadPriority and OptoLoopAlignment were added by JDK-8141042. Fix currently only in hs-rt/hotspot repo. Thus, only remaining 8 flags need ranges specified: AllocatePrefetchDistance AllocatePrefetchInstr CompileThreshold InteriorEntryAlignment NodeLimitFudgeFactor OnStackReplacePercentage PrintNMethodsAtLevel TypeProfileLevel
10-11-2015
The flags with just constraint, but no range, if any should have a default(MIN, MAX) range specified.
09-11-2015