fix(core): spawn blocking ops onto worker pool to avoid stack overflow

[kszucs]

Summary

• Fix SIGSEGV in Java binding's BlockingWriteTest on Linux x86_64 when using HF/XET backend

Root cause

blocking::Operator called Handle::block_on() which polls the entire async state machine on the calling thread's stack. For backends with deep async call chains — HF/XET uploads go through:

block_on (calling thread, 1 MB stack on Linux JVM)
  → RetryLayer::write
    → HfBackend::write
      → HfWriter::try_new
        → xet_upload_commit
          → bridge_async
            → XetUploadCommit::new
              → upload_stream
                → CAS upload tasks

This exceeds the default 1 MB thread stack size on Linux, hitting a guard page → SIGSEGV (SEGV_ACCERR).

Why macOS wasn't affected: macOS default thread stack is 8 MB.
Why pure Rust tests passed: Rust's default thread stack is 8 MB.
Why the JVM crashed without an hs_err file: The overflow happened on the JVM's own thread before its crash handler could activate.

Workaround

Increate java stack size:

diff --git a/bindings/java/pom.xml b/bindings/java/pom.xml
index 575d470fe..e8c46fe9a 100644
--- a/bindings/java/pom.xml
+++ b/bindings/java/pom.xml
@@ -241,6 +241,13 @@
                 <groupId>org.apache.maven.plugins</groupId>
                 <artifactId>maven-surefire-plugin</artifactId>
                 <version>${maven-surefire-plugin.version}</version>
+                <configuration>
+                    <!-- Some storage backends (e.g. HF/XET) flatten deep async
+                         state machines onto the calling thread via block_on(),
+                         which can exceed the default 1 MB thread stack on Linux.
+                         See https://github.com/apache/opendal/issues/7367 -->
+                    <argLine>-Xss8m</argLine>
+                </configuration>
             </plugin>
             <plugin>
                 <groupId>org.apache.maven.plugins</groupId>

Fix

Replace direct Handle::block_on(future) calls with Handle::block_on(Handle::spawn(future)) for the main I/O operations (stat, read, write, copy, rename, delete, list, create_dir).

The async future now runs on tokio worker threads (which have adequate stack space — typically 2-8 MB) while the calling thread only waits on a lightweight JoinHandle. This keeps the calling thread's stack usage minimal regardless of how deep the backend's async state machine goes.

Operations that return streaming handles (reader, writer, lister, deleter) still use direct block_on since they only set up lightweight state — the actual I/O happens through separate blocking wrapper types that already manage their own block_on calls.

Verification

Tested in an x86_64 Docker container (Rosetta) with:

• Java 17 (default -Xss1m)
• HF bucket backend with XET protocol
• BlockingWriteTest — all 3 tests pass without any -Xss workaround

Test plan

• BlockingWriteTest passes on Linux x86_64 via Docker (previously SIGSEGV)
• Async HF write roundtrip still passes on macOS
• cargo check -p opendal-core --features blocking compiles cleanly

Closes #7367

[Xuanwo]

Thank you for figure this out. I will enable hf on java after #7368 been merged.

Also cc @tisonkun to take a look on the java side changes?

[Xuanwo]

Thank you!