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

[Mikael Gerdin]

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