RFR(XS) 8037959: BitMap::resize frees old map before copying memory if !in_resource_area
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
> 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
More information about the hotspot-dev