RFR(XS) 8037959: BitMap::resize frees old map before copying memory if !in_resource_area

[Bengt Rutisson]

Hi Mikael,

The new change looks good to me.

I agree with Thomas suggestion to always set ArrayAllocatorMallocLimit 
in the test. Other than that it looks good. Thanks for adding the test.

Bengt


On 2014-03-26 11:03, Mikael Gerdin wrote:
> Hi,
>
> I've come up with a solution where I add a reallocate() method to
> ArrayAllocator and have BitMap use that for growing its backing memory.
>
> New webrev at: http://cr.openjdk.java.net/~mgerdin/8037959/webrev.1
>
> I didn't generate an incremental webrev since I rewrote the fix from scratch.
>
> As per Bengt's suggestion I added some simple tests for BitMap::resize.
>
> Note: reallocate needs to be in allocation.inline.hpp since ArrayAllocator is
> a class template. Trying to #include copy.inline.hpp would create a horrible
> circular dependency between some of the most basic headers in the VM so I
> resorted to just use memcpy instead to copy the memory.
>
> /Mikael
>
> On Friday 21 March 2014 10.39.14 Mikael Gerdin wrote:
>> Hi all,
>>
>> While reading through the code for BitMap I stumbled across a bug in the
>> resize functionality for bitmaps not allocated in the resource area.
>>
>> The problem is that if a previous backing for the bitmap exists we free the
>> backing memory before attempting to copy its contents to the new backing
>> memory.
>>
>> I've followed the code paths leading to resize so I'm pretty sure this bug
>> is currently benign since we never actually encounter this case but it
>> seems like a good idea to fix this nevertheless.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8037959
>> Webrev: http://cr.openjdk.java.net/~mgerdin/8037959/webrev.0
>>
>> /Mikael