RE: Classpath build process and VM-specific issues

[Jeroen Frijters]

Etienne Gagnon wrote:
> Jeroen Frijters wrote:
> >>>Indeed. The goal is to find the optimal solution that would be spec
> >>>compliant, portable and efficient.
> 
> and later:
> > I'm not the one nitpicking about pure ISO C portability (I don't use
> > JNI, so I couldn't care less), ...
> 
> and later:
> >>and is of thus ranks lower than my proposal on 2 counts:
> >>1- Efficiency:
> > 
> > For a JNI based implementation, maybe, but I'd argue that 
> anyone using
> > JNI doesn't care about performance anyway.
> 
> You contradict yourself.  First you say that the optimal is 
> spec compliant, portable, and efficient.  Then you say that
> you couldn't care less about the spec compliant JNI interface,
> that portability across JVMs/compilers on a single platform is
> of no interest, and that efficiency of JNI is not an objective
> of your proposal.

Let me explain. I don't see Classpath as a monolithic entitity. I see
Classpath as two parts, Java and native. I use the Java part, I don't
use the native part. I care about Classpath as a whole. I think the
native part is valuable (because it increases the value of Classpath as
a whole, it also increases the value of the Java part).

In the particular case we are discussing (memory mapped NIO), I think
that JNI is a lousy interface. I think it will prove to be far too slow,
therefor I want to use the proper abstractions that allow VMs to
optimize these operations. IMHO, RawData is better abstraction than a
byte[] for this particular purpose.

I just wrote a little benchmark comparing byte[] and RawData for reading
bytes (i.e. dereferencing the pointer) and another one that tests
alloc/free. It turns out that RawData is actually marginally faster (in
both cases). This is on x86 32bit on Sun JDK 1.4.1 using standard JNI.

I'm not going to give the code, because that'll just trigger another
round of language lawyering, but I'm convinced that C language issues do
not have any significant impact on the performance of either solution.

For reference, my (partially) optimized implementation of dereferencing
the RawData pointer is almost an order of magnitude faster than the JNI
implementation running on the Sun JVM (and two orders of magnitude
faster than the JNI implementation running on my VM).

Regards,
Jeroen