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

[Mikael Gerdin]

Hi,

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:
> > > 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
> > > 
> >   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
> ArrayAllocator.

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

/Mikael

> > - 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.
> 
> /Mikael
> 
> > Thanks,
> > 
> >   Thomas