RFR 8037925: CMM Testing: an allocated humongous object at the end of the heap should not prevents shrinking the heap

[Andrey Zakharov]

Hi.
Here is updated webrevs
http://cr.openjdk.java.net/~iignatyev/anzakharov/8037924/webrev.14/ 
<http://cr.openjdk.java.net/%7Eiignatyev/anzakharov/8037924/webrev.14/>
http://cr.openjdk.java.net/~iignatyev/anzakharov/8037925/webrev.07/ 
<http://cr.openjdk.java.net/%7Eiignatyev/anzakharov/8037925/webrev.07/>

Thanks.

On 10.04.2014 16:25, Erik Helin wrote:
> Given that the cleanup issue exists and is being worked on, I'm fine 
> with this patch.
>
> Thanks,
> Erik
>
> On 2014-04-10 14:22, Erik Helin wrote:
>> Andrey has updated the patch:
>>
>> http://cr.openjdk.java.net/~ehelin/8037925/webrev.06/
>>
>> The new patch does no longer change the testlibrary. There is already an
>> issue filed for fixing these tests and the previous testlibrary changes:
>> https://bugs.openjdk.java.net/browse/JDK-8039489.
>>
>> Thanks,
>> Erik
>>
>> On 2014-04-02 19:02, Andrey Zakharov wrote:
>>> Hi, Jon
>>> On 02.04.2014 01:21, Jon Masamitsu wrote:
>>>> Seems like an out-of-memory (OOME) can be thrown here (or anywhere 
>>>> below
>>>> this block of code).  Will an OOME be considered a pass, fail or
>>>> test-not-run?
>>> Yes, its really an question for me, from one point of view, we should
>>> catch OOM and move forward to exit(0),
>>> from another point - such things should be handled by test harness. 
>>> Test
>>> should have some @tag about 1G memory its used and harness should skip
>>> test and notify about this if machine memory is below needed.
>>> Maybe there is another right way.
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140411/94922434/attachment.htm>