Question about G1CollectedHeap::print_on()

[Thomas Stüfe]

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?

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.

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/a611e646/attachment.htm>