RFR (M) : JDK-8016029 : test runtime/6878713/Test6878713.sh failed

[Leonid Mesnik]

On 07/18/2013 12:55 AM, Mikhailo Seledtsov wrote:
> Hi Leonid,
>
>  Thank you for pointing out the related bug. I have linked the bugs as 
> "relates to", and will set the other bug as fixed once the original 
> bug moves to a fixed state.
> As for running out of memory, this is helped by specifying 
> "MallocMaxTestWords" in the test.
I remember that this test caused a lot of issues related with running of 
native memory. This is why I so worry about it.

I see that maximum for malloc is 786M. What are RAM requirements for 
this test? We have a lot of hosts with 512M-1G memory (mostly in 
embedded lab).
Should this test works fine on them or it could cause swaping/memory 
exhausting?


Thank you
>
> Misha
>
>
> On 7/17/2013 11:53 AM, Leonid Mesnik wrote:
>> Mikhailo
>>
>> Could you please that your changes fix also
>>   JDK-7037122 runtime/6878713/Test6878713.sh is written incorrectly
>> and close it after push.
>>
>> Can test really run out of native memory on low-end hosts?
>>
>> Leonid
>>
>> On 07/17/2013 12:33 AM, Mikhailo Seledtsov wrote:
>>> Dear Colleagues,
>>>
>>>  Please review this test fix. The change is a fix for the original 
>>> bug, plus an update to the test condition to reflect new JVM 
>>> behavior and a rewrite of an sh script test in Java.
>>>
>>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8016029
>>> Webrev: http://cr.openjdk.java.net/~mseledtsov/6878713/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Emseledtsov/6878713/webrev.00/>
>>>
>>> Here are a few notes:
>>> - the original test used a hand-crafted class file written in java 
>>> assembly, designed to cause a specific OOM condition during class 
>>> file parsing. Since jar/class files are not recommended in the open 
>>> source repository, I have used static byte array's to generate this 
>>> class file. This is not an ideal solution, it would be better to 
>>> create a Java Assembly source; however currently JTREG does not 
>>> support Java Assembly compilation, hence this work-around.
>>>
>>> - the original behavior of the VM in this test case has changed, and 
>>> the expected error message has changed as well. There is an 
>>> extensive amount of information about this in the original bug, 
>>> posted by Dan. The change was introduced in change-set: 
>>> 4876:f75faf51e8c4 by Harold. Checking for the old expected messages 
>>> has been removed from the test. This change is for JDK8 and forward, 
>>> and no back-ports planned.
>>>
>>> - the flag -XX:+IgnoreUnrecognizedVMOptions has been removed to 
>>> avoid masking a potential problem. If VM drops support for any of XX 
>>> flags used in this test, it is better to know about it right away 
>>> rather than mask it and silently pass/ignore.
>>>
>>> - the flag -XX:+PrintCommandLineFlags has been removed; if this 
>>> information is desired, IMO it should be triggered either by a 
>>> verbose mode of JTREG tools, or by hand, not by individual test(s).
>>>
>>> Thank you,
>>> Misha
>>
>>
>


-- 
Leonid Mesnik
JVM SQE