RFR (S): 8016556: G1: Use ArrayAllocator for BitMaps

Bengt Rutisson bengt.rutisson at oracle.com
Fri Jun 14 06:03:24 PDT 2013


Hi Thomas,

On 6/14/13 2:27 PM, Thomas Schatzl wrote:
> [added the CR number in the subject line]

Thanks! :)

>
> Hi,
>
> On Thu, 2013-06-13 at 16:53 +0200, Bengt Rutisson wrote:
>> Hi everyone,
>>
>> Could I have a couple of review for this small change?
>> http://cr.openjdk.java.net/~brutisso/8016556/webrev.00/
>>
> Looks good.

Thanks for looking at this!

>
> A few minor comments which are free to ignore:
>
> - the code in the ArrayAllocator constructor/destructor is now more than
> a line. Some additional spacing between them may help readability.

Good point. Added the line breaks.

>
>> One complication with the fix is that the BitMap data structures get
>> copied around quite a bit. The copies are shallow copies, so we don't
>> risk re-doing the allocation. But since I am now embedding an
>> ArrayAllocator in the BitMap structure the destructor for copies of the
>> ArrayAllocator gets called every now and then. The BitMap explicitly
>> frees up the allocated memory when it thinks it is necessary. So, rather
>> than trying to refactor the code to avoid copying I made it optional to
>> free the allocated memory in the ArrayAllocator desctructor.
> - instead of the "free_in_destructor" name I would prefer something like
> "owner"; but this is really just my personal opinion.

I see your point, but I actually prefer "free_in_destructor". To me 
"owner" suggests a bit too much responsibility. With the current 
implementation it is the BitMap that will own the memory and is 
responsible for calling free() on the ArrayAllocator. I'm open for a 
better name than "free_in_destructor" but I can't really come up with one.

>
>> I do think it would be good to review the BitMap code. It seems a bit
>> fishy that we pass around shallow copies. But I think my current change
>> keeps the same behavior as before.
> I agree about both things :)
:)

Thanks again for looking at this!

Bengt


>
> Thanks,
> Thomas
>
>



More information about the hotspot-dev mailing list