TypedMemory

[mambastudio]

Hi Marco,

I've been developing a library for a while (a lot of research due to bytecode concepts and analysis) called TypedMemory. What if you could model a struct using records and flatten them to native memory. It is based on jdk 25, and takes advantage of FFM and ClassFile-API. Doesn't use any reflection unless during initialisation. It's quite fast, and did some internal benchmarks, and competes quite well with native code (c code, you can find it in the test package). Just released it a few days ago, and published it in maven (hope it reflects soon), but you can give it a try. Tried my best to polish everything including API. Hope this will be useful, since I needed a very nice type model for native memory interoperability, especially when I use device based libraries such as JOCL. Honestly, ClassFile-API is a quite a blessing for java.

Joe.

[gpu]

(Sorry for the delayed response here).

Yes, I remember that we talked about that in gpu/JOCL#25 . You may have seen that JOCL itself hasn't been sooo active for a while. But to some extent, there wasn't "so much to do" for the core library: The library should be somewhat stable, and I think that OpenCL 3.x is not so widely used (or even supported).

I'm also aware of the FFM and ClassFile API, but have to admit that I've been only following that on a somewhat shallow level (i.e. the Sumatra/Panama JDK projects). In fact, most of what I'm doing is still in Java 8. I definitely have to catch up in some areas. Much of the stuff that I've been doing with (tedious) JNI, reflection, and occasionally BCEL is way better supported now on the level of the core API.

And it looks like the 'TypedMemory' project is doing exactly that: From skimming over the README. it looks like it is building the bridge between the 'foreign' package and what has been done with 'JOCLStructs'. But it seems to do this using the new(er) language features like 'record' types, and more importantly: without all the drawbacks of reflection and having to copy memory back and forth.

I have to allocate a bit more time to take a closer look at all this. But if I understood this correctly, then this should be capable of completely replacing any possible use-case of 'JOCLStructs', and offer a (possibly considerable) performance benefit. (There are some specific, low-level details that I'd have to check. For example: You can create "mapped memory" in OpenCL, essentially offering access to GPU memory "as if" it was a host-side void* pointer. Would it be possible to create such a Mem-view on such a mapped memory?)

In any case, thanks for the heads-up, I'll definitely have a closer look at this.