[
https://issues.apache.org/jira/browse/FLINK-21419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17300153#comment-17300153
]
Xintong Song commented on FLINK-21419:
--------------------------------------
[~kezhuw],
I'd be fine with explicitly fail on concurrent frees, as long as we don't fail
for non-concurrent multiple frees. The question is, how does the segment now if
the multiple frees are concurrent or not? Do we need a {{volatile}} variable
indicating whether another thread is in middle of freeing the segment? I'm not
sure if it worth the complexity.
Concerning the memory leak diagnoses, I think you've raised a very good point.
We removed the gc cleaner because:
* We no longer rely on gc for releasing the memory. (all segments now should be
released before being collected)
* It is preferred to reduce hacking into java internals, with reflection, which
may lead to compatibility issues in future java versions.
We could possibility do the following:
* Check whether {{cleaner}} is set to {{null}} in {{finalize()}}, which is
called when the object is collected.
* {{MemoryManager#verifyEmpty()}} is currently called when a slot is being
freed. Currently, it only prints warning logs when the check fails, because
previously the memory might have not been freed yet (relying on GC) when the
slot is freed. I think we can throw a exception now.
WDYT?
> Remove GC cleaner mechanism for unsafe memory segments
> ------------------------------------------------------
>
> Key: FLINK-21419
> URL: https://issues.apache.org/jira/browse/FLINK-21419
> Project: Flink
> Issue Type: Sub-task
> Components: Runtime / Coordination
> Reporter: Xintong Song
> Assignee: Nicholas Jiang
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.13.0
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
