supporting custom JVM intrinsics

[Samuel Audet]

Hi, Maurizio,

Well, John seemed to have a different idea about how you might go on 
supporting C++, where's his blog post about that again.

Anyway, I didn't understand from your idea that you still intended to 
use the C++ compiler to generate stubs, and that these stubs would be 
processed further by the JVM's JIT. Yes, that's how I see it. We can 
have a standard set of stubs for C that wouldn't require support from 
the C compiler, sure.

However, you're still relying on the C compiler to get the layouts, so 
what do you gain, really? Why not make that framework generic from the 
start and let community members like me and Jorn work on those "standard 
calls"?

Samuel

On 2/4/19 4:50 PM, Maurizio Cimadamore wrote:
> On 04/02/2019 01:53, Samuel Audet wrote:
>> I think I've finally found what would satisfy me: custom JVM 
>> instrincs. Vladimir's presentation about how linkToNative is 
>> implemented with those is quite enlightening I find, thank you for 
>> your time on this:
>> http://cr.openjdk.java.net/~vlivanov/talks/2016_JVMLS_MachineCodeSnippets.pdf 
>>
>>
>> Since we're creating new intrinsics for these machine code snippets, 
>> I'm thinking, couldn't we extend the JVM and allow users to plug in 
>> custom intrinsics at will? Right now the API isn't public, and varies 
>> with the JVM, but what if it could be standardized and made 
>> extensible? I also understand that they are hard to develop, but when 
>> I look at examples like those below, and given a limited set of 
>> features to call native functions, for starters, it seems like they 
>> could be generated without too much hassle:
>>
>> https://www.slideshare.net/RednaxelaFX/green-teajug-hotspotintrinsics02232013 
>>
>> https://gist.github.com/rednaxelafx/1986224
>> https://gist.github.com/rednaxelafx/db03ab15ef8b76246b84
>>
>> JavaCPP is essentially already doing that with JNI. It could easily 
>> generate code for JVM intrinsics, effectively targeting some mix of 
>> C/C++ API and assembly code. The overall workflow could be something 
>> like this:
> 
> I think that's more or less how we planned to add support for C++ from 
> the start (if you go back to some of the initial emails we exchanged, 
> you will see me referring to machine code snippets quite frequently, see 
> [1] :-)).
> 
> The only difference, if there's one, is that you seem to imply that we 
> should use custom intrinsics for everything, even standard C ABI calls - 
> whereas in our view custom intrinsics is a weapon to use for case of 
> 'complex non-ABI points'. In other words, standard calls can flow 
> through SystemABI, that part works well and is well optimizable by JITs.
> 
> But if you need to implement a function-like macro, or a virtual C++ 
> function, then it's much better to compile those into something else 
> (with the native compiler) and then have the call happen via some 
> mechanism to embed the generated library into the VM (a la code snippets).
> 
> (Vlad, John, please correct me if wrong, of course!)
> 
> Maurizio
> 
> [1] - 
> https://mail.openjdk.java.net/pipermail/panama-dev/2018-January/000931.html
> 
>>
>> - At build time:
>>     1. Take high-level annotated methods from Java, possibly generated 
>> with a tool like jextract
>>     2. For each method, generate C/C++/assembly code for a custom JVM 
>> intrinsic, probably with the help of a C/C++ compiler
>>     3. Use the C/C++ compiler to build a native library that extends 
>> the JVM as a plugin
>> - At runtime:
>>     4. Load that native library either dynamically, if possible, or as 
>> part of the JVM at boot
>>
>> I don't see many disadvantages to such an approach:
>> - needs native wrappers, but Panama will already need those for inline 
>> functions, macros, and C++ templates anyway
>> - requires a C/C++ compiler, but Panama already bundles Clang, so we 
>> can reuse it when required
>>
>> But I see many advantages:
>> - supports C++ just as efficiently as C
>> - bypasses all the complexities of system/C/C++ ABIs, supporting any 
>> C++ compiler, including MSVC
>> - paves the way to support inlining of native functions/macros/templates
>> - eventually making it possible for the community to map special CPU 
>> instructions for performance--as third-party libraries
>>
>> Now *that's* the kind of thing I would be interested in seeing happen! 
>> Any chance of getting something like that out of Panama? If not, maybe 
>> after Graal goes mainstream, it sounds a lot like its support for 
>> "compiler intrinsics"...
>> http://lafo.ssw.uni-linz.ac.at/papers/2017_PLDI_GraalTutorial.pdf
>>
>> Samuel