RFR: 8231356: Fix broken ResourceObj::operator new[] in debug builds

[Leo Korinth]

On Mon, 9 Aug 2021 14:31:22 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> ResourceObj::operator new[] calls ResourceObj::operator new (non array version). In debug builds, each resource object (on C_HEAP) will be initialized with set_allocation_type() (which is correct). What is not correct is that the constructor (and thus) set_allocation_type() is called on the array itself (which is not a ResourceObj). This initialization will be partially overwritten by the header that keeps track of the array size. When the array destructor later is called, it will also chain call the non-array destructor. In debug builds the verification of _allocation_t[0] will fail as it has been overwritten by the code that keeps track of the array size.
> 
> The following assert will fail:
> assert(~(_allocation_t[0] | allocation_mask) == (uintptr_t)this, "lost resource object");
> 
> The reason that it has not been detected is that no one uses ResourceObj::operator new[] on resource objects with C_HEAP storage.

I should have looked further.... I guess the original author thought it would "align" with the first element of the array (and the array size info strikes again). When I am thinking about it more I suspect and fear that that the scalar "new" does not work correctly either. What guarantee do we have that the memory area will not be overwritten by the constructor? Just because we do not explicitly write over the memory does not give us any guarantee that the constructor will leave the field untouched, right? I guess to make this really correct we would need to remove the information from the ResoureObj and put it in the bytes before the address we return from operator new. That is, operator new ought to allocate a little bit more on debug builds (and not enlarge ResourceObj), and return a pointer a few bytes into the buffer so that the constructor does not overwrite the "type" stored in the first part.

Let me investigate this a bit further. And thanks for finding the extra bugs!

-------------

PR: https://git.openjdk.java.net/jdk/pull/5055