RFR: 8297718: Make NMT free:ing protocol more granular [v2]
Gerard Ziemski
gziemski at openjdk.org
Wed Dec 7 16:44:05 UTC 2022
On Wed, 7 Dec 2022 10:58:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> Matter of taste. I dislike this kind of coding, even though it is common in hotspot, where you have a compound function and a bunch of flags (often uncommented) fine-controlling its behavior. You then end up having to read the code to understand its behavior exactly.
Currently we have gone **from:**
const size_t old_size = MallocTracker::malloc_header(memblock)->size();
void* const old_outer_ptr = MemTracker::record_free(memblock);
**to:**
MallocHeader* header = MallocTracker::malloc_header(memblock);
header->assert_block_integrity(); // Assert block hasn't been tampered with.
const MallocHeader::FreeInfo free_info = header->free_info();
header->mark_block_as_dead();
But the change could have been just **from:**
const size_t old_size = MallocTracker::malloc_header(memblock)->size();
void* const old_outer_ptr = MemTracker::record_free(memblock);
**to:**
MallocHeader* header = MemTracker::record_free(memblock, false);
const MallocHeader::FreeInfo free_info = header->free_info();
Where `header` related APIs are nicely encapsulated and hidden away.
Does `realloc()` really need to know about and do all the header APIs? Before this change `realloc()` only dealt with `MemTracker`, but now we have to deal with `MallocHeader` APIs as well.
-------------
PR: https://git.openjdk.org/jdk/pull/11390
More information about the hotspot-runtime-dev
mailing list