java - Is direct buffer required for JNI / external library calls? -
i want pass addresses of java objects (especially byte arrays) system calls , external functions return within 1 jni call.
the answer openjdk's own jni functions apparently no - instance readbytes/writebytes io_util used file streams introduce direct buffer / heap malloc related external calls.
but, why? checked code in java.nio.bits (copyfromarray) , sun.misc.unsafe (copymemory), , it's clear contents of java primitive arrays can accessed directly in ordinary c code without special treatment (such notifying vm memory pinning or dealing non-continuous blocks) long it's within scope of current jni function. seems gc cannot happen when jni method being invoked, if that's true, why readbytes/writebytes make copy of data in c heap?
anyone experience on this? i'm not seeking official advice/recommendation openjdk or oracle. not interested in portability or beyond current implementations.
pinning array getprimitivearraybytescritical()
lightweight, , meant purpose. jni spec describes explicitly actions can performed between get/release…critical:
after calling getprimitivearraycritical, native code should not run extended period of time before calls releaseprimitivearraycritical. must treat code inside pair of functions running in "critical region." inside critical region, native code must not call other jni functions, or system call may cause current thread block , wait java thread. (for example, current thread must not call read on stream being written java thread.)
also, doc explains jvm might internally represent arrays in different format, , these functions return copy. directbytebuffer
, on contrary, guaranteed in c-compatible format.
the side effects simple experiments not account for, exceptions thrown either in java or in c, access other threads, , - alternative jvm. specs set before 64-bit virtual memory addressing became widespread, , there no strong reason change them.
all jni kind of frozen many years, because "good enough" on 1 hand, , "not important enough" on other, , main concern compatibility, serious challenge in itself, given number of independent implementations.
Comments
Post a Comment