RFR: 10: 8160638: solaris JVM unable to allocate more than 2GB of direct byte buffers when max heap is <= 2GB

Jiangli Zhou jiangli.zhou at oracle.com
Tue Apr 18 17:51:49 UTC 2017


Hi Vladimir,

This looks safe to me. With your change, the HeapBaseMinAddress is adjusted higher with an offset of (MaxDirectMemorySize - 1g) on solaris. It’s done via set_ergonmic_flags(), which is before the HeapBaseMinAddressConstraintFunc check. If the moved HeapBaseMinAddress violates the constraint, it will be caught by the check.

Thanks,
Jiangli

> On Apr 14, 2017, at 5:28 AM, Vladimir Kempik <vladimir.kempik at oracle.com> wrote:
> 
> Can I have somebody to take a look at this please.
> 
> Thanks, Vladimir
> 
> 
> 10.04.17 16:30, Vladimir Kempik пишет:
>> 
>> Hello
>> 
>> Please review this fix for bug JDK-8160638 <https://bugs.openjdk.java.net/browse/JDK-8160638>
>> 
>> The issue is with solaris only.
>> 
>> When java mmaps heap (with compressed Oops enabled), mmaped heap become upper limit for any native mallocs.
>> 
>> So when heap is starting at 2 gb, the maximum we can malloc is 2gb.
>> 
>> Native malloc is used by Direct Memory Buffers, so even with -XX:MaxDirectMemorySize=100g we are still limited with less than 2 gb of memory for Direct Memory Buffers.
>> 
>> The fix moves HeapBaseMinAddress to upper space when it's needed for MaxDirectMemorySize to operate properly, leaving about 1 gb of native memory for java's needs.
>> 
>> Testing: jprt, included testcase.
>> 
>> Webrev - http://cr.openjdk.java.net/~vkempik/8160638/webrev.00/
>> 
>> Bug - https://bugs.openjdk.java.net/browse/JDK-8160638
>> 
>> Thanks, Vladimir
>> 
> 



More information about the hotspot-runtime-dev mailing list