RFR (XS) 8058818: Allocation of more then 1G of memory using Unsafe.allocateMemory is still causi, ng a fatal error on 32bit platforms

[Coleen Phillimore]

Thank you George and David.

On 9/24/14, 9:26 PM, David Holmes wrote:
> On 25/09/2014 8:42 AM, George Triantafillou wrote:
>> Hi Coleen,
>>
>> Looks good, thanks for doing this.
>>
>> In answer to the comment "// Does the option above override if all 
>> the tests are run with NMT???", the JTREG run tag "@run main/othervm" 
>> will run UnsafeMallocLimit2 in a separate VM with the options 
>> specified (-Xmx32m -XX:NativeMemoryTracking=off) in the test.
>
> I thought it also combined them with anything passed via -vmoption on 
> the jtreg invocation? The jtreg docs are unclear on this.
>
> Generally looks okay to me. Two comments on the test:
>
> First this line doesn't quite read correctly:
>
>  41                 // Allocate greater than MALLOC_MAX and possible 
> to allocate.

I reworded to a longer:

                 // Allocate greater than MALLOC_MAX and likely won't 
fail to allocate,
                 // so it hits the NMT code that asserted.
>
> Second, what is the failure mode for test? It seems it passes as long 
> as the VM doesn't crash - is that right?

Yes.   The test allows an OOM, it just doesn't want that fatal error in 
the bug.

Thanks,
Coleen
>
> Thanks,
> David
>
>> -George
>>
>> ----- Original Message -----
>> From: coleen.phillimore at oracle.com
>> To: hotspot-runtime-dev at openjdk.java.net
>> Sent: Wednesday, September 24, 2014 6:23:15 PM GMT -05:00 US/Canada 
>> Eastern
>> Subject: RFR (XS) 8058818: Allocation of more then 1G of memory using 
>> Unsafe.allocateMemory is still causi,ng a fatal error on 32bit platforms
>>
>> Summary: The assert was firing for NMT_Off and minimal too even though
>> the size isn't used.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8058818/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8058818
>>
>> Tested with the NMT tests.
>>
>> thanks,
>> Coleen
>>