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

Daniel D. Daugherty daniel.daugherty at oracle.com
Thu Jul 18 06:54:30 PDT 2013


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
>>>
>>>
>>
>
>



More information about the hotspot-runtime-dev mailing list