slfan1989 commented on code in PR #4167:
URL: https://github.com/apache/amoro/pull/4167#discussion_r3068908101
##########
amoro-format-iceberg/src/main/java/org/apache/amoro/io/writer/SortedPosDeleteWriter.java:
##########
@@ -49,6 +50,25 @@
*/
public class SortedPosDeleteWriter<T> implements Closeable {
private static final long DEFAULT_RECORDS_NUM_THRESHOLD = Long.MAX_VALUE;
+ private static final Runtime RUNTIME = Runtime.getRuntime();
+ private static final HeapUsageProvider RUNTIME_HEAP_USAGE =
+ new HeapUsageProvider() {
+ @Override
+ public long maxMemory() {
+ return RUNTIME.maxMemory();
+ }
+
+ @Override
+ public long usedMemory() {
+ return RUNTIME.totalMemory() - RUNTIME.freeMemory();
Review Comment:
> English Version
Acknowledged. This limitation is documented in the code comments (L53-54).
The current approach prioritizes low overhead and simplicity while ensuring
accuracy when it matters most: when heap approaches maxMemory (the actual OOM
risk window), totalMemory ≈ maxMemory and the calculation is accurate.
More precise alternatives like MemoryPoolMXBean can be added as an optional
strategy in future enhancements, but the current simple implementation provides
the right balance between overhead and OOM protection.
Could we consider implementing this feature in the future?
> Chinese Version
已经确认这个问题，在L53-54添加了代码注释。
当前方案优先考虑低开销和简洁性，同时确保在最关键的时刻（即堆内存接近 maxMemory，实际的 OOM 风险窗口）的准确性：当堆内存接近
maxMemory 时，总内存 ≈ maxMemory，此时计算结果准确。
更精确的替代方案（例如 MemoryPoolMXBean）可以作为未来增强功能中的可选策略，当前简单的实现方案在开销和OOM更平衡一点。
我们可以考虑在未来实现这个功能吗？
--
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]
