jextract woes

[Michael Zucchi]

On 30/1/20 9:58 pm, Maurizio Cimadamore wrote:
>
> On 30/01/2020 05:07, Michael Zucchi wrote:
>> I guess from jorn's email you're talking about creating a an 
>> implementation of an interface through which the calls operate.
>>
>> I think that's frankly beyond the scope of what should be required to 
>> use panama.
>
> All I was trying to say is that there is a way, at the classfile 
> level, to make this idiom of your quite fast - as you can effectively 
> build a polymorphic cache using the MethodHandle and invokedynamic 
> support - so that, as long as the platformID remains constant, the VM 
> will keep treating the native method handle as a constant too.
>
> But all this is quite advanced.
>

Ok right.  I guess as an answer to the question posed I was little "what 
on earth" yesterday and without the context from Jorn it seemed like 
some big part in the middle was missing.

Today isn't really the day but if i were to look into this at some point 
- are the necessary api's public?  Afterall it's part of the technology 
that makes the jvm so "cool" - it's just that compilers just aren't my 
thing.

I would probably start with the invoke.* docs, virtual machine spec, and 
probably the previous jextract stuff which i presume needed to do this 
to implement the annotated interfaces, e.g. Libraries.bind() (from memory).

>>
>>> Or maybe it's overkill, and if your context is 'simple' enough, you 
>>> can just use a map<Context, MethodHandle> :-)
>>>
>>
>> If jextract can't do the functional equivalent of the above i'll just 
>> have to use the code I have already.
>
> I think implementing stuff like this is better done on your side - at 
> least for now. If we added support for this use cases it would have to 
> be something quite general and reusable, and it's not clear (yet, at 
> least - I'd have to think more) to me how something like that would 
> work in a way that is general enough to be ok with all libraries using 
> this idiom.
>
> But thanks for bringing this up - I think it's an interesting use case!

Well given the old jextract Libraries.bind() could be used for this 
within it's high-level binding mechanism it must've been seen as useful 
at one point.

Compared to a (final MethodHandle) where is the benefit (i dont ask this 
facetiously)?  Is it only at classloading/instantiation time or does it 
affect the .invoke() as well?  Given the methodhandle is final and 
constant once it's created is it equivalent in use?  These interfaces 
are only going to be created once for the lifetime of any 'context' 
object.  Could it cost more to create a new class (or edit one) and load 
it than it is to just to instantiate the bits in normal class fields?

...

On zcl specifically i've now got a work-in-progress but working library 
that covers most of what the previous one did and with the same api. I 
haven't considered portability - it's strictly 64-bit + sysvabi for 
now.  The biggest downside vs jni is the pinned array access which 
either forces copies or the caller to change their design; but the 
former is at worst a double copy when single copy would have been used 
so it's kind of 'meh'.

I guess at this point:  in the context of having a library in both 
panama and jni, is there anything that can help this project?  I've got 
old opencl code somewhere i could turn into some tests, like face detection.

I could alternatively look into FFmpeg binding.  I will have to use my 
own generator again - jextract wont even work on the headers now, and it 
wont ever be flexible enough for what is required, but this is 
specifically due to the ffmpeg "it's not really an api" so i wouldn't 
expect it to.  I expect I wont have any big issues getting it working so 
it shouldn't expose any panama shortcomings along the way (i'll need to 
use ForeignUnsafe though - pervasively).  It would be another test point 
though and one I can check easily on windows so I would probably attempt 
a cross-platform version, eventually.

Or maybe vulkan as i want to learn that as well, but that would probably 
take a different approach and have it mostly auto-generated but in an 
application-specific manner so that it's usable directly, if possible.  
The api itself is defined by an xml file (not the c header file although 
that works) so more automation is possible.

Cheers,
  Z