RFR 9: [TESTBUG] 8078582: java/lang/Runtime/exec/LotsOfOutput.java fails intermittently with Process consumes memory

Joseph D. Darcy joe.darcy at oracle.com
Wed May 20 02:28:19 UTC 2015


Hi Roger,

On 5/19/2015 7:25 PM, Roger Riggs wrote:
> Hi Joe,
>
> Thanks, I was pondering on what to do.  The intermittent keyword was 
> not already on this test
> though it has been failing intermittently.
>
> I agree that it is useful for the keyword to remain as a reminder that 
> it was intermittent
> until there is some evidence about long term stability.

An advantage of that policy is that it enables targeted test runs of the 
tests known or suspected of intermittently failing (jtreg 
-k:intermittent ...). Such additional scrutiny should be able to be 
continued after an update to the test has been made so that there is an 
opportunity to verify that the fix holds up and reduces the probability 
of failure.

Thanks,

-Joe

>
> Roger
>
>
> On 5/19/15 10:21 PM, Joseph D. Darcy wrote:
>> On 5/19/2015 7:14 PM, Martin Buchholz wrote:
>>> Thanks, Roger.  This is a much better test now (but still not 
>>> actually a
>>> good one...)
>>>
>>> Probably want to be optimistic and delete
>>>
>>> + * @key intermittent
>>
>> That is an interesting (and as yet unresolved) policy question: how 
>> should removal of intermittent keywords be managed?
>>
>> Although it requires another bug in the future, be default I'd prefer 
>> if the intermittent tag stayed on and was only removed after some 
>> parole period where it was observed to not fail. The length / extent 
>> of this period should be inversely proportional to the probability of 
>> failure.
>>
>> Concretely, if a test fails 1 out of 100 test runs it doesn't need to 
>> be run a long as a test that fails 1 out of 1,000 test runs.
>>
>> -Joe
>>
>>>
>>>
>>>
>>> On Tue, May 19, 2015 at 6:50 PM, Roger Riggs 
>>> <Roger.Riggs at oracle.com> wrote:
>>>
>>>>   Hi,
>>>>
>>>> Ok, how about this:
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rriggs/webrev-lots-8078582/
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>>
>>>> On 5/19/15 7:55 PM, Martin Buchholz wrote:
>>>>
>>>> LotsOfOutput is a lousy test. totalMemory can grow with any quantum.
>>>> Better would be watching
>>>> usedMemory = Runtime.getRuntime().totalMemory() -
>>>> Runtime.getRuntime().freeMemory();
>>>>   as suggested at
>>>>
>>>> http://stackoverflow.com/questions/3571203/what-is-the-exact-meaning-of-runtime-getruntime-totalmemory-and-freememory 
>>>>
>>>>
>>>> On Tue, May 19, 2015 at 2:32 PM, Roger Riggs <Roger.Riggs at oracle.com>
>>>> wrote:
>>>>
>>>>> Please review this update to a test to make it resilient to small
>>>>> allocations
>>>>> that may bump the total memory.  The test will also collect more 
>>>>> data if
>>>>> it fails again.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~rriggs/webrev-xx/
>>>>>
>>>>> Issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8078582
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>




More information about the core-libs-dev mailing list