fix a bug that sometimes hashmap is not released

[badboynt1]

User description

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #18364

What this PR does / why we need it:

fix a bug that sometimes hashmap is not released.
free memory when query finished.

---

PR Type

Bug fix, Enhancement

---

Description

• Refactored hashmap initialization and memory allocation in hashmap_util.go to ensure proper memory management.
• Simplified the Reset method in table_scan/types.go by removing unnecessary freeReceiver calls.
• Improved memory management in JoinMap by introducing FreeMemory and modifying Free method.
• Enhanced message lifecycle management by adding Destroy method to Message interface and implementing cleanup in MessageBoard.
• Added Destroy methods to RuntimeFilterMessage and TopValueMessage for better resource management.

---

Changes walkthrough 📝

	Relevant files
Enhancement	hashmap_util.go Refactor hashmap initialization and memory allocation        pkg/sql/colexec/hashmap_util/hashmap_util.go Moved hashmap initialization to BuildHashmap method. Removed hashmap initialization from Prepare method. Ensured memory allocation is handled within BuildHashmap. +10/-12  joinMapMsg.go Improve memory management in JoinMap                                          pkg/vm/message/joinMapMsg.go Introduced FreeMemory method for memory cleanup. Modified Free method to use FreeMemory. Added Destroy method for JoinMapMsg. +16/-4    message.go Enhance message lifecycle management                                          pkg/vm/message/message.go Added Destroy method to Message interface. Implemented message cleanup in MessageBoard. Removed Free method from MessageReceiver. +5/-13    runtimeFilterMsg.go Add Destroy method to RuntimeFilterMessage                              pkg/vm/message/runtimeFilterMsg.go Added Destroy method to RuntimeFilterMessage. +3/-0      topValueMsg.go Implement Destroy method in TopValueMessage                            pkg/vm/message/topValueMsg.go Added Destroy method to TopValueMessage. Reorganized imports. +5/-1
Bug fix	types.go Simplify TableScan reset logic                                                      pkg/sql/colexec/table_scan/types.go Removed freeReceiver method. Simplified Reset method by removing unnecessary calls. +0/-8      scope.go Remove unnecessary Free call in scope handling                      pkg/sql/compile/scope.go Removed Free call on msgReceiver. +0/-1

---

💡 PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

[qodo-merge-pro]

PR-Agent was enabled for this repository. To continue using it, please link your git user with your CodiumAI identity here.

PR Reviewer Guide 🔍

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Key issues to review Potential Performance Issue The hashmap initialization is now done inside the BuildHashmap function, which could potentially be called multiple times. This might lead to unnecessary allocations and deallocations. Memory Management The new FreeMemory method is introduced, but it's not clear if it's being called in all necessary places to prevent memory leaks. Potential Resource Leak The Free method of MessageReceiver has been removed. It's not clear if its functionality is replaced elsewhere, which could lead to resource leaks.

[qodo-merge-pro]

PR-Agent was enabled for this repository. To continue using it, please link your git user with your CodiumAI identity here.

PR Code Suggestions ✨

Category	Suggestion	Score
Best practice	Use defer to ensure cleanup is always performed Consider using a defer statement to ensure that jm.FreeMemory() is always called when Free() is executed, even if the function panics or returns early. pkg/vm/message/joinMapMsg.go [127-132] func (jm *JoinMap) Free() { if atomic.AddInt64(&jm.refCnt, -1) != 0 { return } - jm.FreeMemory() + defer jm.FreeMemory() } Apply this suggestion Suggestion importance[1-10]: 8 Why: Using defer ensures that cleanup is always performed, which is a best practice for resource management and error handling. This suggestion enhances code reliability.	8
Enhancement	Refactor hashmap initialization into a separate method for better code organization Consider moving the hashmap initialization logic to a separate method to improve code organization and reusability. This will also make the BuildHashmap function more focused on its primary responsibility. pkg/sql/colexec/hashmap_util/hashmap_util.go [188-198] -if hb.keyWidth <= 8 { - if hb.IntHashMap, err = hashmap.NewIntHashMap(false, proc.Mp()); err != nil { - return err - } - itr = hb.IntHashMap.NewIterator() -} else { - if hb.StrHashMap, err = hashmap.NewStrMap(false, proc.Mp()); err != nil { - return err - } - itr = hb.StrHashMap.NewIterator() +if err = hb.initializeHashmap(proc); err != nil { + return err } +itr = hb.getHashmapIterator() Apply this suggestion Suggestion importance[1-10]: 7 Why: This suggestion improves code organization and readability by refactoring the hashmap initialization into a separate method. It is a good practice for maintainability, although not critical for functionality.	7
Performance	Optimize message destruction by considering object pooling Consider using a more efficient approach to destroy messages, such as implementing a custom pool or using sync.Pool to reuse message objects instead of creating and destroying them frequently. pkg/vm/message/message.go [148-151] for i := range m.messages { - message := *m.messages[i] - message.Destroy() + m.messages[i].Destroy() + // Consider returning the message to a pool here + // messagePool.Put(m.messages[i]) } Apply this suggestion Suggestion importance[1-10]: 6 Why: While this suggestion could improve performance by reducing garbage collection overhead, it is not immediately necessary unless profiling shows message creation/destruction as a bottleneck.	6
Possible issue	Implement proper cleanup logic in the Destroy method The Destroy() method is currently empty. Consider implementing proper cleanup logic if there are any resources that need to be released when a TopValueMessage is no longer needed. pkg/vm/message/topValueMsg.go [46-47] func (t TopValueMessage) Destroy() { + // Add cleanup logic here if needed + // For example: + // t.someResource.Close() + // t.someSlice = nil } Apply this suggestion Suggestion importance[1-10]: 5 Why: This suggestion highlights a potential issue but lacks specific details on what resources need cleanup. It is a reminder to ensure proper resource management if applicable.	5