Are java.lang classes better served by the JVM?

[Charles Oliver Nutter]

On Sun, Sep 30, 2012 at 5:00 PM, Mark Roos <mroos at roos.com> wrote:
> But it does bring to mind a comment
> John Rose made at the
> 2010 JVMLS about how it would be cool if a method handle could refer to some
> native code.  It seems
> like this would get at least some of what you want.

Actually, I don't think I ever talked about how we're using indy in
our java/native integration layer.

Wayne Meissner, our native integration guy (has worked on jna and most
recently created jnr-*) started playing with both invokedynamic and
native code generation.

So if you have a Ruby FFI binding like this:

ffi_lib LibC
attach_function :getpid, [], :uint

All Ruby call sites that eventually call getpid get wired via method
handles all the way to the eventual native downcall. Everything
inlines except the native bit. On the other side of the native logic,
Wayne uses jnr-x86asm to generate the logic libffi would do
programmatically for every call. So the logic basically goes:

Ruby call site => JNI downcall => target library function

It's about as fast as it can be, and only 5-6x slower (overhead-wise)
than calling the function from C directly (for e.g. getpid that has
almost no overhead of its own).

If it were possible to make the method handle point at the target
library function or our ASM stub around it, I'd be happy :)

> It seems like this is already possible ( I have not tried it ) as method
> handles can wrapper a native method.  So what us dynamic
> folks need is a way to generate the native code on the fly.  And of course
> it would be nice if JNI calls were inlined.  I see an
> example in LLVM where the JIT facet of LLVM is used to generate single C
> functions.  The seems to be what we need.  On the
> fly code generation and then using method handles to substitute them at
> runtime.  Of course JNI could be slow.
>
> And thoughts of if this would work?  And any reading suggestions to get a
> better handle on the details?

Well, a native method is just a Java declaration + a
properly-structured dylib to match up with it. JNI calls don't inline
right now, as far as I know, so the best we could do is basically what
JRuby does now for FFI stuff. Have you taken a look at jnr-x86asm?

- Charlie