RFR 7179383 (was Re: -XX:MaxDirectMemorySize argument parsing)

[Staffan Larsen]

Looks good!

/Staffan

On 25 jun 2012, at 07:20, David Holmes wrote:

> Sorry for the delay on this Chris. I've filed 7179383 and generated a webrev:
> 
> http://cr.openjdk.java.net/~dholmes/7179383/webrev/
> 
> Still need an additional runtime reviewer.
> 
> Thanks,
> David
> 
> On 11/06/2012 11:18 PM, Chris Dennis wrote:
>> 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,
>>>>> right?
>>>>> 
>>>>> Chris
>>>> 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.
>>> 
>>> David
>>> 
>>>> -Alan
>>