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

Bengt Rutisson bengt.rutisson at oracle.com
Wed Mar 26 15:39:18 UTC 2014

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.


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

More information about the hotspot-dev mailing list