Building CUDA bindings for Windows with jextract

[John Rose]

On Feb 18, 2019, at 10:35 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
>> THIS IS FINE! I guess. In a native program, trying to access GPU memory from the main C program causes a segfault and a nasty crash. I guess this is what is captured with the InternalError in general. So in fact, this is positive: It does NOT crash the VM and generate a "hs_err" log, but graciously uses an exception to tell the programmer that he messed things up.
> 
> Well, yes - accessing non DRAM memory via Unsafe is bound to fail in mysterious ways. I'm less positive than you are re. gracefulness, in the sense that I don't know under which condition the VM is able to recover after a bad Unsafe::put/get. I would expect the mileage might vary here - but I'm no VM engineer and I'll leave this specific point to others.

+1 The InternalError here is a last-ditch attempt by the VM to avoid
a hard crash.  This is legitimate for a few use cases, specifically
mapped byte buffers where the underlying file has been truncated
externally.  Such events are deemed by the VM designers to require
a continuable error.  But in this case, it's just a bit of luck that the
erroneous code gets IE instead of a hard crash.

Most misuse of raw pointers will get crashes or random behavior.

The JVM can add value here by systematically catching dangling
pointer errors, but this usually requires the extracted API to be
manually upgraded ("civilized") by putting more specific type,
bounds, and scope information on pointers manipulated by
a particular API.  Most of the work so far on Panama is oriented
towards producing raw, unsafe bindings, plus runtime support
for the basic infrastructure ("back end") of the upgrade process.
There's lots more to do to civilize extracted APIs.

For a current example of a systematic framework for upgrading raw
imported C++ APIs, via JNI, see the preset mechanism of JavaCPP.

— John