-XX:MaxDirectMemorySize argument parsing
cdennis at terracottatech.com
Mon Jun 11 06:18:06 PDT 2012
On Jun 7, 2012, at 9:41 PM, David Holmes wrote:
> On 8/06/2012 12:20 AM, Alan Bateman wrote:
>> On 07/06/2012 14:28, Chris Dennis wrote:
>>> Yes, I'm listed under "Terracotta Inc. (Christopher Dennis)".
>>> There is one additional complication to this in that the
>>> LimitDirectMemory test in the jdk sources is currently broken. The
>>> patch below "fixes" the test - but leaves two open questions:
>>> What should the grep be looking for? This is JDK test asserting on
>>> output generated by Hotspot - that seems a little screwed up to me,
>> it might be nicer to just check the exit code and not depend on the
>> error message.
> Agreed. Seems cleaner.
Okay, I'll prepare a second jdk patch that modifies this test to use the exit value of the JVM as the indicator of startup failure. Once we have a bug-id for this issue I'll propose the test patch on the relevant mailing list referencing the upcoming behavior change and our desire for a more hotspot-neutral test assertion.
Alan: What would the correct forest to provide and patch against and which mailing list should I post it to?
>> Just on logistics, as hotspot and jdk changes take a
>> different route into master it means that we'll need to wait until the
>> hotspot changes get to jdk8/jdk8 (and probably down to jdk8/tl) before
>> pushing a change to the LimitDirectMemory.sh test.
> Also is the hotspot fix targeted for 8 and 7u, or just 8?
I'm not sure if this question was intended for me, but as far as I'm aware currently this change doesn't even have a bug-id. Personally, I don't see the pressing need to have it merged back to 7u, and not doing so would help mitigate the backwards-compatibility issue of the subtle changes it makes in the behavior of the switch.
> Still need additional reviewer from runtime - thanks.
More information about the hotspot-runtime-dev