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

[Leonid Mesnik]

Dan

Thank you for explanation.

Mikhailo
Fix is good. I don't have any questions more.


Leonid

On 07/18/2013 05:54 PM, Daniel D. Daugherty wrote:
> On 7/18/13 3:06 AM, Leonid Mesnik wrote:
>> 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?
>
> Keith's original test caused something larger than 2GB to be attempted
> to be allocated in order to get an overflow that caused a memory stomp.
> The reason for the 768MB upper limit is so that the test would fail to
> allocate quickly.
>
> The test should be fine on small memory machines as long as they don't
> take "forever" to fail the "bad allocation".
>
> Dan
>
>
>>
>>
>> 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