WGPUSync.instanceRequestAdapter returns a broken WGPUAdapter

[ShadelessFox]

On Windows 11, Temurin 24.0.1+9, the following snippet fails against 0.4.3:

import club.doki7.ffm.library.ILibraryLoader;
import club.doki7.webgpu.WGPU;
import club.doki7.webgpu.WGPUSync;

public class Demo {
    public static void main(String[] args) {
        var wgpu = new WGPU(ILibraryLoader.platformLoader().loadLibrary("..."));
        var instance = wgpu.createInstance(null);
        var adapter = WGPUSync.instanceRequestAdapter(wgpu, instance, null).adapter;
        var device = WGPUSync.adapterRequestDevice(wgpu, adapter, null).device;
    }
}

Exception in thread "main" java.lang.RuntimeException: java.lang.IllegalStateException: Already closed
	at club.doki7.webgpu.WGPU.adapterRequestDevice(WGPU.java:538)
	at club.doki7.webgpu.WGPUSync.adapterRequestDevice(WGPUSync.java:93)
	at sh.adelessfox.demo.Demo.main(Demo.java:12)
Caused by: java.lang.IllegalStateException: Already closed
	at java.base/jdk.internal.foreign.MemorySessionImpl.alreadyClosed(MemorySessionImpl.java:318)
	at java.base/jdk.internal.misc.ScopedMemoryAccess$ScopedAccessError.newRuntimeException(ScopedMemoryAccess.java:114)
	at java.base/jdk.internal.foreign.MemorySessionImpl.checkValidState(MemorySessionImpl.java:217)
	at java.base/jdk.internal.foreign.ConfinedSession.acquire0(ConfinedSession.java:53)
	at club.doki7.webgpu.WGPU.adapterRequestDevice(WGPU.java:531)
	... 2 more

Which is interesting because I didn't encounter the same issue on Linux.

I have discovered that FFM upcalls on Windows use a confined arena for allocating their arguments. When an upcall returns, its arena is closed, and all its MemorySegment arguments become invalid. I haven't investigated why it doesn't happen on Linux, though.

The workaround is to use the raw address of a segment:

MemorySegment.ofAddress(segment.address())

An example patch for WGPUSync#onRequestDeviceFinished (please note that WGPUSync#adapterRequestDevice is affected as well):

    private static void onRequestDeviceFinished(
            ...
    ) {
        @Nullable WGPUDevice deviceHandle = device == MemorySegment.NULL
                ? null
-               : new WGPUDevice(device);
+               : new WGPUDevice(MemorySegment.ofAddress(device.address()));
        @Nullable String messageString = WGPUUtil.readStringView(message);
        saveSlot.value = new RequestDeviceResult(status, deviceHandle, messageString);
    }

[chuigda]

Hi, I've reproduced the issue.

I have discovered that FFM upcalls on Windows use a confined arena for allocating their arguments. When an upcall returns, its arena is closed, and all its MemorySegment arguments become invalid.

Do you have any link to relevant posts/questions/answers/issues? If this is true, I'm afraid that this is rather an issue of Java FFM itself: such "FFI-returned" MemorySegment should theoretically not be considered allocated at all.

I'll still make a patch from my side. And before the release of next patch version (v0.4.5), you can temporarily live with your own fork of WGPUSync. Also feel free to request (or contribute) more utility functions.

[ShadelessFox]

Do you have any link to relevant posts/questions/answers/issues?

No... I tried googling to no avail, unfortunately.

I'll still make a patch from my side.

Thank you for the quick resolution!

[chuigda]

Ok I've got a reproduction:

---

ccb.c:

#include <stdint.h>

typedef struct {
    char const *s1;
    char const *s2;
    char const *s3;
} S;

typedef void (*callback_fn)(S s, void *data);

#ifdef _MSC_VER
#define EXPORT __declspec(dllexport)
#else
#define EXPORT __attribute__((visibility("default")))
#endif

EXPORT extern void ccb(callback_fn fn) {
    fn(
        ((S) {
            "Shall I leave you be,",
            "Is it love if I can set you free?",
            "But even it's not reality,",
        }),
        "Let's be together, forever, we are never gonna be apart."
    );
}

---

CCB.java:

import java.lang.foreign.*;
import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;

public final class CCB {
    static final StructLayout LAYOUT$S = MemoryLayout.structLayout(
            ValueLayout.ADDRESS.withTargetLayout(ValueLayout.JAVA_BYTE).withName("s1"),
            ValueLayout.ADDRESS.withTargetLayout(ValueLayout.JAVA_BYTE).withName("s2"),
            ValueLayout.ADDRESS.withTargetLayout(ValueLayout.JAVA_BYTE).withName("s3")
    );

    static final FunctionDescriptor DESCRIPTOR$ccb = FunctionDescriptor.ofVoid(ValueLayout.ADDRESS.withName("fn"));

    static final MethodHandle hCCB;
    static {
        System.loadLibrary("ccb");

        Linker linker = Linker.nativeLinker();
        SymbolLookup stdlibLookup = linker.defaultLookup();
        SymbolLookup loaderLookup = SymbolLookup.loaderLookup();

        MemorySegment pfnCCB = loaderLookup.find("ccb")
                .or(() -> stdlibLookup.find("ccb"))
                .orElse(MemorySegment.NULL);
        if (pfnCCB.equals(MemorySegment.NULL)) {
            throw new RuntimeException("Failed to find ccb symbol");
        }
        hCCB = linker.downcallHandle(pfnCCB, DESCRIPTOR$ccb);
    }

    static final class Ref<T> {
        T value;
    }

    @FunctionalInterface
    interface MemorySegmentConsumer {
        void accept(MemorySegment segment);
    }

    static void callback(MemorySegmentConsumer consumer, MemorySegment s, MemorySegment data) {
        for (int i = 0; i < 3; i++) {
            MemorySegment segment = s.getAtIndex(ValueLayout.ADDRESS, i).reinterpret(Long.MAX_VALUE);
            System.out.println("Segment " + i + ": " + segment.getString(0));
        }
        data = data.reinterpret(Long.MAX_VALUE);
        System.out.println("Data: " + data.getString(0));

        consumer.accept(data);
    }

    static final FunctionDescriptor DESCRIPTOR$callback = FunctionDescriptor.ofVoid(
            LAYOUT$S,
            ValueLayout.ADDRESS
    );

    public static void main(String[] args) {
        Ref<MemorySegment> ref = new Ref<>();
        MemorySegmentConsumer consumer = segment -> ref.value = segment;

        try (Arena arena = Arena.ofConfined()) {
            Linker linker = Linker.nativeLinker();
            MethodHandle MH$callback = MethodHandles.lookup().findStatic(
                    CCB.class,
                    "callback",
                    DESCRIPTOR$callback.toMethodType().insertParameterTypes(0, MemorySegmentConsumer.class)
            );
            MemorySegment pfnCallback = linker.upcallStub(
                    MH$callback.bindTo(consumer),
                    DESCRIPTOR$callback,
                    arena
            );

            hCCB.invokeExact(pfnCallback);

            System.out.println("Callback called with segment: " + ref.value.getString(0));
        } catch (Throwable e) {
            throw new RuntimeException(e);
        }

        System.out.println("Try retrieving segment after arena closed: " + ref.value.getString(0));
    }
}

---

The point seems to be "a callback function accepting a struct". The accepted struct needs to be allocated on a local, confined arena. Technically speaking the rest pointers do not need to be allocated on, and are not allocated by such arena, but on Windows platform these rest pointers behaves as if they are allocated from the same arena. I guess this could be bug of JVM in the worst case. I'll try gathering more information.

[chuigda]

Opened StackOverflow question: https://stackoverflow.com/questions/79700202/weird-behaviour-of-java-ffm-on-windows-platform-when-creating-upcalls-accepting

Update: this has been confirmed to be a bug of FFM implementation: https://stackoverflow.com/a/79700269/14312575

And, thank you for participating Doki Doki!