JDK-8308501 : Replacement of SortedLinkList in NMT with other more efficient data structures
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 21
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2023-05-22
  • Updated: 2024-07-25
  • Resolved: 2024-07-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 24
24Resolved
Related Reports
Blocks :  
JDK-8263464 - NMT: assert in gtest os.release_multi_mappings_vm
Duplicate :  
JDK-8337217 - Port VirtualMemoryTracker to use VMATree
Description
It perceives a long time for the user to get the detailed list of allocated memory instances, due to sorting the list(s). It can be investigated that if this long time can be shortened.
Comments
Hi Thomas, An interval tree could be useful, but it seems perhaps a bit complex to implement? I don't know if the fact that we're bounded to [0, 2**64) helps since the tree will be so very sparse. I'd like to understand the sizes of our virtual memory tracker on real applications a bit better before deciding on anything, perhaps the constant cost of traversing through a tree will be larger than simpler iteration methods?
19-11-2023
For address ranges, maybe something like an interval tree would be a better data structure? https://en.wikipedia.org/wiki/Interval_tree
01-08-2023
To expand a bit: What currently is implemented is a linked list approach approximately as such: class ReservedMemory { static SortedLinkedList<ReservedMemory> rlist; SortedLinkedList<CommittedMemory> clist; }; This has caused the code to be very finicky to implement, see: PRs made to enhance and fix bugs in this area. My suggestion is instead to separate these concerns into arrays. I believe that this will improve performance and readability of the code. We'd have: struct MemoryRange { void* addr; size_t len; }; GrowableArray<MemoryRange> ReservedMemory; GrowableArray<MemoryRange> CommittedMemory; Playing around with this in a prototype has shown that some things which are very tricky to get right in the current structure is extremely straight forward in this arrangement.
16-07-2023