[
https://issues.apache.org/jira/browse/FLINK-21798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303047#comment-17303047
]
Kezhu Wang commented on FLINK-21798:
------------------------------------
Inspired by [pr-15246|https://github.com/apache/flink/pull/15246], I think if
all these unsafe usages(current and possible future) are restricted in
{{MemoryManager}}, they {{MemoryManager}} itself serves as guard for both
multiple frees and safety net.
If this is the case, then I recommend:
* Restrict {{allocateOffHeapUnsafeMemory}} to package private
* Does not free native memory in {{free}}. It is trick, but the root is
implementation agnostic usages of {{MemorySegment}}. It is contract between
workhorse and caller whether workhorse is responsible for {{free}}.
* Backdoor package private {{freeUnsafe}} for {{MemoryManager}}.
* Document more explicitly that {{MemorySegment}} from {{MemoryManager}}
should only be "freed" through {{MemoryManager.release}} variants.
* Obsolete this issue and FLINK-21799.
This way, these segments are more "managed". Please ignore my words if
precondition does not meet.
cc [~xintongsong] [~trohrmann] [~dwysakowicz]
> Guard MemorySegment against multiple frees.
> -------------------------------------------
>
> Key: FLINK-21798
> URL: https://issues.apache.org/jira/browse/FLINK-21798
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Coordination
> Reporter: Xintong Song
> Priority: Critical
> Labels: Umbrella
> Fix For: 1.13.0
>
>
> As discussed in FLINK-21419, freeing a memory segment for multiple times
> usually indicates the ownership of the segment is unclear. It would be good
> to gradually getting rid of all such multiple-frees.
> This ticket serves as an umbrella for detected multiple-free cases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
