RFR(XS) 8037959: BitMap::resize frees old map before copying memory if !in_resource_area
mikael.gerdin at oracle.com
Wed Mar 26 11:38:40 UTC 2014
On Wednesday 26 March 2014 12.36.16 Thomas Schatzl wrote:
> Hi Mikael,
> On Wed, 2014-03-26 at 12:25 +0100, Mikael Gerdin wrote:
> > Hi Thomas,
> > On Wednesday 26 March 2014 12.01.02 Thomas Schatzl wrote:
> > > 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.>
> > > - 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.
> I was concerned about the use of memcpy() in that case in the
> implementation of reallocate(). I looked at it again, and it should be
> okay after all.
> If _addr is still NULL, memcpy does not access _addr at all since the
> size given is zero.
> So disregard this comment :)
Ok, thanks for bringing it up though. It's not entirely obvious.
More information about the hotspot-dev