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