7172708: 32/64 bit type issues on Windows

[Alan Bateman]

On 04/06/2012 14:38, Chris Dennis wrote:
> :
>
> The patch to increase test coverage to cover this issue is against the jdk sources, however the issue here is more complicated.  While modifying the LimitDirectMemory.sh jtreg test to cover this issue I've run in to some problems with the test - the code that is intended to test the parsing of 'illegal' values was broken.  I've 'fixed' this code in the patch to approximate the current behavior of the tip of the jdk7u-dev forest, but the test doesn't currently pass with these modifications (it fails for -XX:MaxDirectMemorySize=-1).  It's not clear to me to what extent the details of the behavior for these illegal values is important: is the text of the message important, is the current behavior with -1 a problem?  I'm also not sure whether these test changes should be part of a separate commit under a different bug-id?
>
> As a further question (I seem to be full of questions today - sorry!) should the jdk changes go through the jdk8 forest first before being merged in to jdk7u-dev or are we okay to go in the other direction?
>
Yes, the rule is that jdk changes should be in jdk8 first and then 
back-ported.

If you are adding coverage to this test then the important thing is that 
it be reliable on all platforms, including 32-bit. I see you've extended 
the test to run with -XX:MaxDirectMemorySize=5g but that isn't going to 
work on 32-bit. I would suggest that -XX:MaxDirectMemorySize=-1 be 
considered an error (I think that will be consistent with the error 
handling for other heap sizing options).

-Alan