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

Mikael Gerdin mikael.gerdin at oracle.com
Wed Mar 26 10:03:29 UTC 2014


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.


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