RFR[XS] 8210043 Invalid assert(HeapBaseMinAddress > 0) in ReservedHeapSpace::initialize_compressed_heap
Ioi Lam
ioi.lam at oracle.com
Tue Aug 28 21:30:46 UTC 2018
Hi Jiangli,
I think the current code is pretty self-explanatory -- we will try to
map at any arbitrary address specified by the user, but there's no
guarantee that it will succeed.
I don't think there's need to specifically talk about
HeapBaseMinAddress==0, as the user might just as well specify
HeapBaseMinAddress=12345678 and that doesn't affect the logic.
// Attempt to alloc at user-given address.
if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) {
try_reserve_heap(size + noaccess_prefix, alignment, large,
aligned_heap_base_min_address);
if (_base != aligned_heap_base_min_address) { // Enforce this exact
address.
release();
}
}
Thanks
- Ioi
On 8/28/18 1:45 PM, Jiangli Zhou wrote:
> Hi Ioi,
>
> Thanks for the additional explanation. Just did some more experiments.
> With '-Xmx1024m -XX:HeapBaseMinAddress=0', the VM allocates the java
> heap at the same address range as with '-Xmx1024m' (when the default
> HeapBaseMinAddress is taking effect). That eased my concern. Also, the
> existing argument checks guarantee that negative value cannot be
> passed to HeapBaseMinAddress. Based on those, it seems removing the
> assert is ok. Could you please add a comment in
> ReservedHeapSpace::initialize_compressed_heap() with the explanation
> for the 0 HeapBaseMinAddress case?
>
> Thanks,
>
> Jiangli
>
>
> On 8/28/18 11:18 AM, Ioi Lam wrote:
>> Hi Jiangli,
>>
>> Thanks for the review.
>>
>> The VM doesn’t really have any ideas of what’s a good value for
>> HeapBaseMinAddress. All it does is to try to map the address as given
>> by the user. If it fails, then the VM will ask the os to allocate a
>> block at an address picked by the os.
>>
>> The mapping at 0 will invariably fail, because on all OSes this range
>> is not mappable by the user program.
>>
>> When MaxHeapSize is not set, the GC ergonomics code tries to pick a
>> “good” address that is likely to work well for compressed oops, etc.
>> I think that’s why it overrides HeapBaseMinAddress (although there’s
>> no comment so I don’t know exactly why). However, if MaxHeapSize and
>> HeapBaseMinAddress are both specified by the user, the user probably
>> knows what they are doing and I don’t think the VM should interfere.
>>
>> As I mentioned above, picking any HeapMinAddress is safe as the VM
>> will simply ignore the values that don’t work.
>>
>> Thanks
>> Ioi
>>
>>
>>> On Aug 28, 2018, at 10:46 AM, Jiangli Zhou <jiangli.zhou at oracle.com>
>>> wrote:
>>>
>>> Hi Ioi,
>>>
>>> This probably is not a safe change and masks the bug that happens
>>> elsewhere. When running with '-XX:HeapBaseMinAddress=0 -version',
>>> Arguments::set_heap_size() resets HeapBaseMinAddress to
>>> DefaultHeapBaseMinAddress. That's why the assert in
>>> ReservedHeapSpace::initialize_compressed_heap() is not hit.
>>>
>>> I just ran '-Xmx1024m -XX:HeapBaseMinAddress=0' in gdb. Adjusting
>>> the HeapBaseMinAddress is not happening in this case because
>>> MaxHeapSize is not default. That causes 0 being seen as the
>>> HeapBaseMinAddress later in
>>> ReservedHeapSpace::initialize_compressed_heap().
>>>
>>> Thanks,
>>>
>>> Jiangli
>>>
>>>
>>>> On 8/27/18 11:18 PM, Ioi Lam wrote:
>>>> Hi, please review this one-liner change:
>>>>
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8210043
>>>>
>>>> There is code that ensures HeapBaseMinAddress >=
>>>> DefaultHeapBaseMinAddress,
>>>> but that happens only when MaxHeapSize is default, so the assert
>>>> doesn't match
>>>> the existing behavior.
>>>>
>>>> The JVM works just fine if we remove the assert.
>>>>
>>>> $ hg diff src/hotspot/share/memory/virtualspace.cpp
>>>> diff -r 2e928420389d src/hotspot/share/memory/virtualspace.cpp
>>>> --- a/src/hotspot/share/memory/virtualspace.cpp Tue Aug 21
>>>> 20:23:34 2018 -0700
>>>> +++ b/src/hotspot/share/memory/virtualspace.cpp Mon Aug 27
>>>> 23:05:18 2018 -0700
>>>> @@ -490,7 +490,6 @@
>>>> guarantee(size + noaccess_prefix_size(alignment) <=
>>>> OopEncodingHeapMax,
>>>> "can not allocate compressed oop heap for this size");
>>>> guarantee(alignment == MAX2(alignment,
>>>> (size_t)os::vm_page_size()), "alignment too small");
>>>> - assert(HeapBaseMinAddress > 0, "sanity");
>>>>
>>>> const size_t granularity = os::vm_allocation_granularity();
>>>> assert((size & (granularity - 1)) == 0,
>>>>
>
More information about the hotspot-runtime-dev
mailing list