jextract woes

Fri Jan 31 15:27:40 UTC 2020

On 31/01/2020 03:53, Michael Zucchi wrote:
> 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).
All the relevant API public in java.lang.invoke, yes. Plus the SystemABI 
API in jdk.foreign.incubator.
>
>>>
>>>> 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?
I'm not sure I get what you are asking here - I'm pretty sure the old 
Libraries.bind could not be used for things like the ones you described. 
The only difference between old and new is that in the old world, 
Libraries.bind was actually generating a brand new class - at runtime - 
to implement a given interface (generated by jextract) based on the 
contents of some annotations. If you want to use something like that in 
a core framework like the JDK you realize that you are pulling in more 
dependencies than really needed - in fact the JDK wouldn't even start if 
we tried to use the binder-based approach because that was trying to 
parse annotation and spin classfiles _while_ the JDK itself was still 
being initialized. So, in terms of footprint and dependencies, the new 
approach is much better - some preliminary tests I did using an OpenGL 
demo, the time to first drawn frame dropped 4x when switching to the new 
bindings. And there's lots of room for improvements (generating 
classfile could make all the MH initialization lazy, which means you pay 
only for the MH you use).
>
> ...
>
> 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 think it would be helpful to collect some numbers from a non-trivial 
example (like the one you had in mind) and see how does Panama fare - 
although I suspect the big penalty in invoking native methods, combined 
with the suboptimal initialization will initially provide not so great 
number - but at least we'll have data to look at.
>
> 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.
This also sounds good - it would also be great if you could write up 
more on why FFmpeg is special - perhaps some of the uses cases cannot be 
addressed, but we could always learn something useful.
>
> 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.

Every experiment helps gaining more understanding on (i) what are the 
limits of the new API when it comes to usability (ii) whether we're 
getting good performances or not (or where the bottlenecks are) and 
(iii) whether there are things that jextract could do to make 
developers's life easier. Of course we're doing our testing and 
validation too - but the more libraries, the better.

Thanks
Maurizio

>
> Cheers,
>  Z
>