Question about G1CollectedHeap::print_on()

[Thomas Stüfe]

Hi Stefan

On Wed, Oct 11, 2017 at 2:43 PM, Stefan Johansson <
stefan.johansson at oracle.com> wrote:

> Hi Thomas,
>
> On 2017-10-11 14:16, Thomas Stüfe wrote:
>
> Hi Stefan,
>
> On Wed, Oct 11, 2017 at 1:52 PM, Stefan Johansson <
> stefan.johansson at oracle.com> wrote:
>
>> Hi Thomas,
>>
>> Seems like you found a bug here. As you say, for G1 the "commit
>> watermark" doesn't really make sense, because we can have regions
>> uncommitted in the middle of the heap. I think we print the value to look
>> similar to the other heaps/GCs. The bug here is that we don't multiply with
>> the region size, but just add it. So we should change the row in question
>> to:
>>   p2i(_hrm.reserved().start() + (_hrm.length() * HeapRegion::GrainWords)),
>>
>> This would give a better value. It would not be the whole truth, since
>> there might still be objects above this address if we have uncommitted
>> regions in the heap. I better value might be "highest region committed" *
>> "heap region size", but that would lie because not all memory below that
>> has to be committed.
>>
>> I created a bug for this:
>> https://bugs.openjdk.java.net/browse/JDK-8189169
>>
>>
> Thank you for taking a look.
>
> Would it not make more sense to just omit the middle address value then
> for g1?
>
> Yes, that might actually make most sense.
>
>
> If I understand HeapRegionManager::commit_regions() / uncommit_regions()
> correctly, comitted and uncomitted regions can freely interleave, and
> _hrm.length() is just a counter, not an address range. So we would print a
> theoretical address value - the end of the committed memory if all regions
> were located consecutively. But how useful could that be?
>
> When I look at the commit boundary value in hs-err files, I usually do
> this to check if a heap pointer points into valid memory or into uncomitted
> memory. For that, I would prefer the value to be exact or not be there.
>
> I agree, this was the part about "not the whole truth". And I agree with
> you, the best way is probably to just remove it. I never use this value for
> G1, I always look at the region table to check if pointers are valid or not.
>
>
Good Point, there is that. Thank you!
..Thomas


> Thanks,
> Stefan
>
> Thanks, Thomas
>
>
>> Cheers,
>> Stefan
>>
>>
>>
>> On 2017-10-11 12:48, Thomas Stüfe wrote:
>>
>>> Hi all,
>>>
>>> In a customer error file I found the following output:
>>>
>>> Heap:
>>>  garbage-first heap   total 2592768K, used 1914672K [0x0000000679000000,
>>> 0x0000000679104f20, 0x00000007f0000000).
>>>
>>> I wonder about the middle address value (0x0000000679104f20). I was
>>> assuming this to be the commit watermark. But the value seemed awfully low
>>> - just ~1MB beyond the start address of the reserved area. Given that about
>>> 4/5th of the heap is in-use, this seemed odd.
>>>
>>> Looking at the code:
>>>
>>> void G1CollectedHeap::print_on(outputStream* st) const {
>>> ....
>>>   st->print(" [" PTR_FORMAT ", " PTR_FORMAT ", " PTR_FORMAT ")",
>>>             p2i(_hrm.reserved().start()),
>>>         >>    p2i(_hrm.reserved().start() + _hrm.length() +
>>> HeapRegion::GrainWords), <<
>>>             p2i(_hrm.reserved().end()));
>>> ...
>>> }
>>>
>>> I am still confused. What is "_hrm.reserved().start() + _hrm.length() +
>>> HeapRegion::GrainWords"?  We add the number of comitted heap regions to the
>>> start address, plus the size of one heap region in words? Sorry, I am not a
>>> GC expert, could someone clarify what this address is?
>>>
>>> Another question, while looking further into how g1 commits memory I
>>> looked at G1PageBasedVirtualSpace and it seems to me that there is no clear
>>> commit water mark because pages do not have to be committed sequentially,
>>> is that correct?
>>>
>>> Thanks for clarifying!
>>>
>>> Kind Regards, Thomas
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20171011/1be4eca5/attachment.htm>