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
