zhoulii opened a new issue, #7909:
URL: https://github.com/apache/paimon/issues/7909

   ### Search before asking
   
   - [x] I searched in the [issues](https://github.com/apache/paimon/issues) 
and found nothing similar.
   
   
   ### Paimon version
   
   1.4
   
   ### Compute Engine
   
   flink 1.18
   
   ### Minimal reproduce step
   
   **Problem**
   
   LazyField keeps a strong reference to the supplier even after the lazy value 
has been evaluated and cached. This causes a memory leak when LazyField 
instances are chained together, such as in GlobalIndexResult.or() / 
GlobalIndexResult.and() operations.
   
   Reproduction Scenario
   In UnionGlobalIndexReader#union(), when there are N readers (e.g., 500), the 
code builds a chain of lazy GlobalIndexResult objects:
   
   Java
   for (Optional<GlobalIndexResult> current : results) {
       ...
       result = Optional.of(result.get().or(current.get()));
   }
   Each GlobalIndexResult.or() creates a new lazy result via:
   
   Java
   default GlobalIndexResult or(GlobalIndexResult other) {
       return create(() -> RoaringNavigableMap64.or(this.results(), 
other.results()));
   }
   This produces a chain: K499 → K498 → K497 → ... → K1, where each node's 
lambda closure captures the previous node.
   
   When the final result is evaluated (calling results()), all intermediate 
RoaringNavigableMap64 bitmaps are computed. However, because LazyField never 
releases the supplier, all intermediate closures and their captured objects 
remain reachable, preventing GC from reclaiming the intermediate bitmaps.
   
   With 500 readers, this results in ~499 intermediate bitmaps permanently 
retained in memory, with total memory usage approximately O(N²) of the final 
bitmap size (since each intermediate is a growing superset).
   
   ### What doesn't meet your expectations?
   
   should null out the supplier reference after evaluation to break the closure 
chain and allow GC to reclaim intermediate objects.
   
   
   ### Anything else?
   
   _No response_
   
   ### Are you willing to submit a PR?
   
   - [x] I'm willing to submit a PR!


-- 
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]

Reply via email to