Request for code review (smallish)

[Keith McGuigan]

Hello,

I'd appreciate any review on this code which I'm offering as a fix for 
bug 6721093: "-XX:AppendRatio=N not supported":

http://webrev.invokedynamic.info/kamg/6721093/

To resolve this, I expanded on the mechanism in place to ignore certain 
unrecognized command-line flags that were previously supported 
(obsoleted flags).  As much as I abhor the standardized use of the 
obviously unsupported -XX flags by certain applications, it 
unfortunately does occur and cause problems for users when upgrading a JDK.

The existing mechanism to address this printed out warnings when a 
previously supported flag was used, with the expectation that we would 
remove those warnings and fail when the command-line flag was present in 
later releases.  Unfortunately with HSX, the same VM goes into different 
JDKs so it's a little harder to make the determination whether we should 
warn or fail when these flags are present.

Conceptually, it is relatively straightforward to add a JDK version 
'limit' before which warnings are printed for these obsoleted flags, and 
errors occur for later JDKs.  So for example, -XX:+UseTrainGC will 
generate an warning and be ignored for JDK6, but passing a flag will 
cause a startup error in JDK7.  This gives the application developers 
adequate warning to stop using a flag.

I've added this capability in the argument processing step, but the 
implementation turned out a bit tricky because of 
order-of-initialization issues.  Namely, discovery of the JDK version 
occurs during initialization after the flags are already processed, and 
JDK version initialization depends on HPI and Thread to be initialized, 
and that's not done before argument processing either.  So to resolve 
this, I modified the initialization paths used by JDK version 
initialization to remove dependencies on HPI and Thread initialization. 
  To do this, I moved a small part of the HPI to the OS interface layer 
(a couple of dll functions) and modified the code paths used by 
JDK_Version  initialization to use the OS versions instead of HPI.  I 
figured this is a good thing anyway as one of our goals is to move away 
from HPI altogether - this is just a baby step in that direction.

So as a result of these changes, JDK_Version can be discovered much 
earlier in the initialization process and thus can be used by argument 
processing or any other early init that might need it (another good 
side-effect, I think).

Apologies for the long-windedness of the explanation, I think you'll 
find that the code changes themselves are probably less than my text, 
but I figured I ought to give a good justification for the seemingly 
unrelated changes to the core system for the simple result of "ignoring 
a command-line flag".

--
- Keith