dwsmith1983 commented on PR #5613: URL: https://github.com/apache/datafusion-comet/pull/5613#issuecomment-5618399763
> Could a declined anchor be non-fatal instead? Done that way. `with_bridge` no longer errors on a zero grant: the pool is created with `anchor_held` unset and `jvm_held` at zero, and `try_grow` calls `take_missing_anchor` before the reserve step, which issues a standalone one byte acquire while the flag is unset and never touches the real request. Once the byte lands the flag is set, so the retry is one extra JNI call per grow only while Spark keeps declining. Two grows retrying at once both get a byte; the second to lock hands its own back and books nothing. `Drop` returns the anchor only when it is held. A bridge error at construction still fails construction, since that is a JNI failure rather than memory pressure. The short-grant branch in `with_bridge` is gone with it, and `const _: () = assert!(ANCHOR_BYTES == 1)` next to the constant pins the reasoning that a declined anchor is a zero grant with nothing to hand back. The comment above the construction acquire now says why it needs no `catch_unwind` (nothing reserved yet to roll back, and `try_unwrap_or_throw` catches the panic at the JNI boundary), and the retry carries the same note. Tests: the declined-at-setup case now asserts the pool exists holding nothing, reports a short grant while the sibling still holds the share, takes the byte on the first grow after the share frees, makes exactly one JVM call per grow from then on, and returns the byte at drop; a second test pins that a pool that never held the anchor releases nothing on drop; a third drives two retries into the stub's acquire gate before either wins and checks one anchor is kept and one byte returned. Thirty loops in debug and release, no failures. On #5466: left a note there proposing that whoever lands second rebases, with the per-reservation basis applied to the reserve-under-lock step rather than replacing it. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
