Question about G1CollectedHeap::print_on()

[Stefan Johansson]

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 <mailto: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
>     <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.

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