Are java.lang classes better served by the JVM?

[BGB]

On 10/1/2012 1:26 AM, Mark Roos wrote:
> From Charles
> Have you taken a look at jnr-x86asm?
>
> No,  but I just bookmarked it to talk a look.  I had been looking at 
> JNA as a way to connect to native
> libs.   Is there some way for me to locate/search for the jRuby native 
> handler code that uses jnr?
>
> I was looking at LLVM with the thought of optimizing the code I 
> generate on the fly.  Perhaps some
> fairly large sets.  The idea would be to generate a 'static' Smalltalk 
> using the PIC information on types.,
> convert it to C and then give it to LLVM to work over.  The other area 
> I am concerned about it the GWT
> for large or specialized ( integer ) callSites.  This is much more 
> limited and may be a good spot for jnr.
> In the later case I would be more concerned about the JNI overhead
>

this reminds me of something, don't know if relevant (this may be a 
tangent, sorry in advance):

has anyone really considered basically writing a tool to read C headers 
and uses automatic code generation for most of the cross-language gluing?...


in my case, I am doing something like:
tool reads C headers, and spits out a database of everything it sees;
when FFI magic is needed by the VM, it fetches the metadata from the 
databases, spits out any intermediate machine code, and uses this to 
interface with the native code.

a partial issue (making this less convenient for the JVM) is that there 
is no good (Java-side) mechanism for linking against the native code 
(apart from ugly hackery, like making an entire C-land library or header 
pose as a synthetic class...).


in my script language, the script-level interface is done via constructs 
like "native import C.whatever;", and "native package C.whatever".

"native import" is used to import things from C land. in this case, it 
imported a "package", which could contain functions directly. a Java 
adaptation would more likely need to treat it as a synthetic class (say, 
the compiler reads the database, and pretends that the class in question 
exists).
(possibly, a physical class-file could be generated, containing 
signatures for those methods which were accessed, the main alternative 
probably being putting the database into the JAR).

"native package" is used to export APIs to C (a tool was used to handle 
the C-side API exporting, basically spitting out a header and some 
trampoline functions and similar to handle calls back into the VM code). 
basically, marking it "native" is an "export this stuff" hint to the tools.

I like my mechanism, mostly because it (along with a few other 
features), allows making it easier to largely ignore the split between 
the code running inside and outside the VM (because I am lazy and don't 
like having to write boilerplate to do cross-language calls or data 
sharing). (I like to compare it to the ' extern "C" ' mechanism in C++, 
where despite there being a cross-language border, it can largely be 
ignored for the most part by programmers).

admittedly, I have little idea if similar would be a viable option for 
the JVM.


(if anyone actually cares, they can ask me and I can send them the 
source for the header-parsing / database-generation tool at least).


or such...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20121001/ae4b1ffb/attachment.html