Panama feedback

[Maurizio Cimadamore]

On 31/03/2020 14:06, Ty Young wrote:
>
> On 3/30/20 6:48 PM, Maurizio Cimadamore wrote:
>> I hear you - one of the reasons we might want an allocator other than 
>> malloc, beside performance, is precisely this: diagnosability 
>> (especially if such allocator would be used JDK-wide, even by native 
>> code). This of course doesn't fully protect from native memory 
>> allocated by the API, but it would cover all the one allocated via 
>> the memory segment API.
>>
>> Then there's the problem of forgetting to close() some segments; and 
>> I think Netty did some experiments in this area to run the code in a 
>> special, slower mode which reported error for every buffer which 
>> became unreacheable before its close method could be called. 
>> Something along those lines could be added.
>
>
> IMO, just like with the "warn" option of jdk.incubator.foreign.Foreign 
> system property, there needs to be more information than simply 
> "WARNING: MemoryAddress reference handle has become unreachable!". 
> There needs to be a robust, IDE hookable solution so that native 
> memory allocated via Panama can be viewed just like normal on-heap JVM 
> memory. Simply spamming doesn't provide enough useful information.
Long term I agree
>
>
<snip>
>
>
> FWIW, I think just skipping any struct that uses a not included type 
> is the best option here. Attempting to make guesses as to what 
> something is will probably end badly.

I think here it would be nice to understand how to improve the current 
jextract API to make these kind of things more easily configurable. The 
main idea is that it should be possible for people to do this by just 
using a Java program (which you can then launch using the single source 
launcher) so the difference between tool and API client is fairly thin.

Note that other languages, namely Rust have already gone down the API 
path pretty heavily:

https://rust-lang.github.io/rust-bindgen/tutorial-3.html

They also have a command-line tool which does some basic things (but I 
suspect, not _all_ of them). So, one thing we need to investigate here 
is what do we need to make the existing API more useful.

I think the parsing part is ok - but we need to add few things:

* a supported tree rewriter transformer (this is not trivial to get 
right, since some types depend back on declaration trees)
* we should have a default code generator, so that developers can 
filter, transform all they want and then delegate back to standard 
generator - not everybody will be in the business of rolling out a 
custom generator

If we do these things, my feeling is that it would be a breeze for you 
to just take the API, filter out everything that is not a struct type 
and just generate the bindings. (or make it more configurable, e.g. 
through a json file).

>
>
>>>
>>> A minor API gripes is that, *currently, there is no way to create 
>>> zero length arrays.* I think this can be added by introducing 
>>> "INVALID" constant SequenceLayout which, when passed to 
>>> AllocateNative, results in AllocateNative returning 
>>> MemoryAddress.NULL. Since the byte size of MemoryAddress.NULL is 
>>> zero, I feel like this should be a safe thing to do.
>>
>> Uhm - not sure; why would you want to create the layout of a 
>> zero-length array?
>
>
> Specifically for functions like this:
>
>
> https://docs.nvidia.com/deploy/nvml-api/group__nvmlDeviceQueries.html#group__nvmlDeviceQueries_1g7eacf7fa7ba4f4485d166736bf31195e 
>
>
>
> In other words, arrays which depend on another pointer's value which 
> may be 0. This can result in situations where code might run fine on 
> one persons computer(or same computer, different config) but not on 
> another, as with the function above.
>
>
> You can just do manual safeguard checks, yes, but someone might not 
> know or forget them.

So, what you want is creating a segment that has zero length. This seems 
very ad-hoc, I don't think I like the idea of adding that ability to the 
API, since a zero-length segment cannot really be closed, etc.

I think what you want is some API on top to create an array given an 
element layout and size and which returns a MemoryAddress

e.g.

MemoryAddress allocateArray(MemoryLayout elementLayout, long size) {
     if (size == 0L) return MemoryAddress.NULL
     else { ... create segment and return base address ... }
}


>
>
>> You mean? Passing Java code as a function pointer to some native 
>> call? Sure there is a way to do that! If this is really what you are 
>> looking for I can give you pointer to some examples using that feature.
>
>
> Yes, please!

This test:

https://github.com/openjdk/panama-foreign/blob/63d3ee093a881e92dd57b1090c3fb7ebec1c4c15/test/jdk/java/foreign/StdLibTest.java#L310

is using an upcall for the qsort comparator. Should contain all the 
relevant bits.


>
>
>> One question for you - given some feedback you gave recently on some 
>> of the messages I posted on a pull request; after having tried this 
>> stuff some more, what is your feeling towards the choice of making 
>> native pointers non-de-referenceable by default? You seemed to be 
>> very skeptical at first on this one - but your message the other day 
>> gave me the impression that you might have a different opinion now; 
>> is my reading correct? E.g. is it something that, after getting used 
>> to, gets better, or that you don't bump into it too often, or is it 
>> just plain annoying - based your experiments?
>
>
> I don't think my views on anything specific within Panama's foreign 
> memory access API has changed in any major way but rather how I view 
> the API as a whole has. Coming from the old Pointer API I was 
> expecting a power drill but what I found was a screwdriver. As someone 
> who doesn't really care about the bindings himself, it wasn't(and 
> still isn't) ideal.
That's a fair point, and also the main result of the course correction. 
While at some point in the future we might come back and look at the 
power drill, for now it is crucial to validate that the screwdriver we 
provide is flexible enough to build abstractions on top. And it seems 
that, while certain things might not be ideal (but we still have some 
ways to go, so that's normal), overall it seems like we can support 
(albeit at a lower level) the same use cases we were able to support 
before (at least this is the feeling we have from our internal 
experiments), but in a more general way, which does not preclude us to, 
eventually, add support for other foreign languages too.


Thanks
Maurizio