RFR (M): JDK-8040722: G1: Clean up usages of heap_region_containing

Jon Masamitsu jon.masamitsu at oracle.com
Wed Apr 16 23:15:58 UTC 2014


On 4/16/2014 12:08 PM, Bengt Rutisson wrote:
>
> Hi Jon,
>
> Thanks for looking at this!
>
> On 4/16/14 6:06 PM, Jon Masamitsu wrote:
>> Bengt,
>>
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp.frames.html 
>>
>>>    45 G1CollectedHeap::heap_region_containing_raw(const T addr) const {
>>>    46   assert(addr != NULL, "invariant");
>> heap_region_containing_raw() does an assertion check against
>> null and heap_region_containing() uses heap_region_containing_raw()
>> so is the null checking assertion at calls to 
>> heap_region_containing() useful?
>> For example here
>>
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html 
>>
>>
>> 2953 Space* G1CollectedHeap::space_containing(const void* addr) const {
>> 2954   assert(addr != NULL, "invariant");
>> 2955   return heap_region_containing(addr);
>
> I'm fine with removing these asserts, I just figured that it would be 
> nice to catch any issues one frame earlier than in 
> heap_region_containing(). But provided that we get good stack traces I 
> guess it is fine to let the assert in heap_region_containing_raw() 
> catch the issues.
>
> Unless anybody else objects I'll remove those extra asserts.

Seems 1 less line of code in several places but I'm fine with either way.

>>
>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp.frames.html 
>>
>>
>>>    32   assert(addr != NULL, "addr must be != NULL");
>>>    33   assert(addr < heap_end(),
>>>    34                 err_msg("addr: "PTR_FORMAT" end: "PTR_FORMAT, 
>>> addr, heap_end()));
>>>    35   assert(addr >= heap_bottom(),
>>>    36         err_msg("addr: "PTR_FORMAT" bottom: "PTR_FORMAT, addr, 
>>> heap_bottom()));
>>>    37
>>
>> Don't need assertion at 32.  Assertion at 35 should caught the addr 
>> !=NULL case or
>> heap_bottom() is NULL in which case addr == NULL is a legal address.
>
> Right. I was actually going back and forth on this assert anyway. I'll 
> remove it.

Thanks.

>
>>
>> heap_region_containing_raw() no longer does the check for 
>> continuousHumongous.
>> heap_region_containing_raw() is called from lots of places. For example,
>>
>>  130 inline void ConcurrentMark::count_region(MemRegion mr, uint 
>> worker_id) {
>>  131   HeapWord* addr = mr.start();
>>  132   HeapRegion* hr = _g1h->heap_region_containing_raw(addr);
>>  133   count_region(mr, hr, worker_id);
>>  134 }
>>
>> Is that OK?  Should it now call heap_region_containing()?
>
> I think you missed that heap_region_containing_raw() and 
> heap_region_containing() have switched places in 
> g1CollectedHeap.inline.hpp. I had to do that to get the inlining right 
> now when heap_region_containing() calls heap_region_containing_raw().
>
> So, heap_region_containing_raw() has not changed. Thus, all calls to 
> it should still be correct.

Ok.

>
>>
>> Maybe we can improve on the name heap_region_containing_raw()
>> (the "raw" conveying little information).
>>
>> Would
>>
>> heap_region_containing_raw -> 
>> heap_region_containing_ignore_continuousHumongous
>>
>> be an improvement.  A bit long, I'll admit.  I'm OK with
>> heap_region_containing_ICH if the declaration explained what
>> the ICH stood for.
>
> I agree that heap_region_containing_raw() is not a great name. 
> However, it does not ignore continues humongous regions. It is 
> heap_region_containing() that does that. So, I guess your naming 
> suggestion would be for heap_region_containing() to change to 
> heap_region_containing_ignore_continues_humongous(), right?
>
> With my patch for allocating objects into the last continues region of 
> a humongous object heap_region_containing() will also be able to 
> return continues regions occasionally. So, I'm not convinced about the 
> name.
>
> Would it be ok to leave the names as they are for now?

That's fine.  That will give us a chance to come up with an
even better name.

Reviewed.

Jon

>
> Thanks,
> Bengt
>>
>> Jon
>>
>> On 4/16/2014 6:46 AM, Bengt Rutisson wrote:
>>>
>>> Hi everyone,
>>>
>>> Could I please have a few reviews of this cleanup?
>>>
>>> http://cr.openjdk.java.net/~brutisso/8040722/webrev.00/
>>>
>>> Background:
>>>
>>> Before the perm gen was removed 
>>> G1CollectedHeap::heap_region_containing() could return NULL for 
>>> addresses in the perm gen. This means that a lot of code had to 
>>> check the result since it could potentially be NULL.
>>>
>>> Now the only reason to return NULL is if the address passed in NULL. 
>>> In many places it is possible to know that the address is not NULL 
>>> and in the other places it is just as simple to check the address 
>>> for NULL before calling G1CollectedHeap::heap_region_containing() 
>>> rather than checking for NULL after having called it.
>>>
>>> So, to simplify the code a bit we can assert that 
>>> G1CollectedHeap::heap_region_containing() never returns NULL and 
>>> then only check before we call it in the places where we would 
>>> otherwise have passed NULL to it.
>>>
>>> Thanks,
>>> Bengt
>>
>




More information about the hotspot-gc-dev mailing list