Re: [Jikesrvm-core] Malloc and GC

[Michael M. <me...@ya...>]

Okay I'll bite : )

First I'm not trying to fit any theoretical model here
I'm just trying to come up with a useful tool.
Theoretically JNI and freedom to move objects may be a
good thing TM but in reality there is a vast body of
native code that is difficult to access from Java. My
main motivation is that in another project I wrote JNI
wrappers for basically the entire X11 api after that
experience I do not believe that the current JNI
native interface is useful for large integration
projects.
To put it bluntly JNI sucks : ) 
Think about it this way if JNI was a value add product
sold by Sun would you buy it ?

Next current JVM implementations contian powerful
dynamic native compilers Java makes minimal use of
these systems. I believe we have not begun to explore
the full power of dynamic compilers.

The result is I'm looking at the internal dynamic
compiler capabilites laying there unused and this
horrible static binding api and saying hmmmmm I bet I
can come up with and easy to use interface between
"native" and java code.

In the context of a dynamic compiler Java VS native
code is really a matter of when code was compiled.
In my work I've written a Elf library loader in java
and the beginings of a way to integrate this code into
a running JVM from this experience it seems quit
doable to develop a JVM which can be extended with a
mix of Java wrapper classes and precompiled native
code without JNI. 

One advantage is that in real JNI code you end up with
a lot of pointers being cached in java as longs or
ints this approach would hopefully remove the need for
such hacks.  Also I'm not just suggesting changes to
the JVM but also once a good binding is in place
changes to the C compilers similar to the C++ changes
to compile java compatible native code.  For C this
may mean some small changes to the way structs are
compiled to match the java object memory model. I'm
saying make C structs java objects not make java
object C structs.

Now with these changes it looks like it may be easy to
convert the "C" code to java once the target java
object model has been defined the Dynamic JNI code
becomes a template for a converter.




--- Eliot Moss <mo...@fr...> wrote:
> One warning bell here .....
> 
> Java is defined so that te JVM has COMPLETE FREEDOM
> in laying objects
> out. In my opinion, this is primarily A GOOD THING.
> Some GCTk (and I
> assume, forthcoming JMTk) memory management systems
> attempt to use this to
> good advantage. It does not mesh well with the
> notion that a Java
> declaration can be directly translated to a C
> struct, without further
> knowledge, etc.
> 
> On the other hand, JNI provides was ways for C code
> to access fields of
> Java objects -- even relatively efficiently ways,
> uch as finding out the
> offset of field "bar" in class "foo". This seems to
> me a better way of
> handling things than trying to spit out matching C
> structs, and more what
> was intending in JNI.
> 
> Basically, I'm saying "Don't try to force Java into
> a C box."
> 
> Something to think about ....
> 
> -- Eliot
> _______________________________________________
> Jikesrvm-core mailing list
> Jik...@ww...
>
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-core


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com