With some more benchmarking and hacking it looks like I can get the same speedup by just modifying VMChannel.java. I suspect that the JikesRVM opt compiler is actually optimizing away the allocation of the ByteBuffer (my version of VMChannel unpacks it).
I still strongly suspect that rewriting the native interface to pass a byte[] and int parameters will be a win across the board (and not bother with ByteBuffers), but that's for someone else to do. cheers > Attached is a patch that changes the native interface of VMChannel, and > allows the VM to change the way FileInputStream and FileOutputStreams > allocate ByteBuffers. > > With a suitably written VMChannel.java, this achieves a 40% speedup on > DaCapo xalan on JikesRVM's 'production' configuration (less on SemiSpace > and more on MarkSweep). > > One option I looked at was avoiding using a ByteBuffer altogether, passing > a byte array, offset and length right the way through the native > interface, but the speedup was negligible (I think the JIT actually > inlines and eventually optimizes away the calls to position() and limit() > on the buffer). > > for consideration and comment. > > regards, > Robin
