RocMarshal commented on code in PR #23589:
URL: https://github.com/apache/flink/pull/23589#discussion_r1375909800
##########
flink-streaming-java/src/main/java/org/apache/flink/streaming/api/graph/StreamConfig.java:
##########
@@ -795,6 +795,20 @@ public boolean isGraphContainingLoops() {
return config.getBoolean(GRAPH_CONTAINING_LOOPS, false);
}
+ /**
+ * In general, we don't clear any configuration. However, the {@link
#SERIALIZED_UDF} may be
+ * very large when operator includes some large objects, the
SERIALIZED_UDF is used to create a
+ * StreamOperator and usually only needs to be called once. {@link
#CHAINED_TASK_CONFIG} may be
+ * large as well due to the StreamConfig of all non-head operators in
OperatorChain will be
+ * serialized and stored in CHAINED_TASK_CONFIG. They can be cleared to
reduce the memory after
+ * StreamTask is initialized. If so, TM will have more memory during
running. See FLINK-33315
+ * and FLINK-33317 for more information.
+ */
+ public void clearInitialConfigs() {
+ config.removeKey(SERIALIZED_UDF);
+ config.removeKey(CHAINED_TASK_CONFIG);
+ }
Review Comment:
Do we want to release this part of memory faster here?
If so, Maybe we could call some native methods so that the JVM can reach the
safe point faster. For example, calling the `Thread. sleep (0L)` method.
Of course, whether this portion of memory can be reclaimed as quickly as
possible largely depends on the implementation of the JVM.
Just a minor comment~
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
