RFR(XS) 8037959: BitMap::resize frees old map before copying memory if !in_resource_area
bengt.rutisson at oracle.com
Wed Apr 2 07:49:51 UTC 2014
On 2014-03-28 13:40, Mikael Gerdin wrote:
> On Wednesday 26 March 2014 12.25.21 Mikael Gerdin wrote:
>> Hi Thomas,
>> On Wednesday 26 March 2014 12.01.02 Thomas Schatzl wrote:
>>> Hi Mikael,
>>> On Wed, 2014-03-26 at 11:03 +0100, Mikael Gerdin wrote:
>>>> 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
>>> looks okay, two minor nits:
>>> - in the test testResizeNonResource(), is it possible to set the
>>> ArrayAllocatorMallocLimit in both cases? Command line flags may set that
>>> to a value that makes the first test equal to the second.
>> Good point, that way I can make sure that I hit both paths in
> I've added a test for the default value of ArrayAllocatorMallocLimit and cases
> to test both allowing and disallowing malloc use.
> Incremental webrev: http://cr.openjdk.java.net/~mgerdin/8037959/webrev.1.to.2
> Full webrev: http://cr.openjdk.java.net/~mgerdin/8037959/webrev.2
>>> - ArrayAllocator::reallocate should verify that this is indeed a
>>> reallocation and not called incorrectly, i.e. _addr is non-NULL.
>> I was attempting to follow the way libc realloc(ptr, sz) works, if you pass
>> ptr as null it degenerates to a malloc(sz).
>> If I change it to a "pure" realloc I would need to change BitMap to keep
>> track of its previous allocations or ask ArrayAllocator if anything is
>> already allocated as well since the call from BitMap's constructor to
>> resize is also the only way in which BitMap allocates memory.
More information about the hotspot-dev