RFR: 8269537: memset() is called after operator new [v3]

Leo Korinth lkorinth at openjdk.java.net
Tue Oct 5 20:57:07 UTC 2021


On Sun, 26 Sep 2021 04:50:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thanks Ioi for making me adding the assert!!! The sequencing of the allocation function and the arguments to the constructor is not what I thought, so my "solution" is not working. I am unsure how to resolve this in a good way. We could probably have a small thread local collection of (type, address) pairs, but I wonder if it is not better removing this debug information altogether. It is to my knowledge only used in GrowableArray (to limit the type of its internal allocations) and to hinder delete on resource allocated objects.
>
> A collection of (type, address) pairs is still problematic.  It still requires assuming that the address of the derived object is the same as the address of the ResourceObj subobject, which isn't guaranteed, though the current mechanism also depends on that being true.  I think there might be other places in HotSpot where we're making that assumption too, unfortunately.

I used your idea of using a triplet to be sure that the derived object is within the created allocation. This solution can still fail if using multiple inheritance (no regression from today) or if allocation is done recursively (but then an assert will trigger). I think this is better than what we have today. If someone wants to remove this debug information in the future I would not argue against it.

In the latest update I changed two classes that faked to be `ResourceObj`. I made them proper `ResourceObj`. I also made `allocation_type` a uint8_t and changed the code a bit so that `operator new` does not call `operator new`. I also made `BufferSize` 5. This could be anything >= 2 for clang at the moment, an assert will trigger if this size is too small.

I have run the tests on tier1-tier3 on linux-x64, linux-x64-debug, linux-x86-debug, macosx-x64-debug, windows-x64-debug.

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

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


More information about the serviceability-dev mailing list