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