Hello Robin, Am Sonntag, den 28.01.2007, 19:15 +1100 schrieb Robin Garner: > I've been looking into why JikesRVM sucks so badly on the DaCapo xalan > benchmark (it's approx 20x slower than the commercial JVMs). > > One of the characteristics of this benchmark (at least in its current > incarnation) is that it does a very large number of 1- and 2-byte file > write operations. JikesRVM currently uses the default reference VMChannel > implementation, which crosses the Java->native boundary with the call > > static native int read(int fd, ByteBuffer buf); > > The C implementation then uses JNI to invoke methods on the ByteBuffer to > get its length and I/O start position, obtain a pointer to the backing > array, release the array and write the new position back to the buffer. > > > Allocating a direct buffer for buf, and adding the interface method > > static native int read(int fd, ByteBuffer buf, int len, int pos); > > and writing the buffer position back in Java halves the execution time of > the benchmark. (the 'write' method is implemented identically) > > > This still leaves the issue of arranging for buf to be a direct byte > buffer. In my current patch I've modified FileInputStream.java to > arrange for a direct buffer to be used, but this doesn't seem very > satisfactory. What I would like to do is intercept the ByteBuffer.wrap > method and do 'the optimal thing', eg use the user's buffer as a > DirectBuffer if it is in a non-moving space, or something less optimal > otherwise, and back this up with a static analysis that allocates I/O > buffers in a non-moving space if it can. > > There's stuff I can do in JikesRVM to speed up the native calls, eliminate > some of the buffer copies etc but the further back in the call chain I do > it (ie in this code) the more scope there is for optimization. > > > So my questions to the list are: > - If I was to contribute the above reimplementation of read and write, > would it be accepted ? Or should I pursue a JikesRVM-specific approach ? > - What is the best way to put a VM-specific hook into ByteBuffer.wrap ? > Is there an existing facility I've missed ? > > > Of course adding a BufferedWriter also solves the performance problem for > xalan, but the commercial class libraries seem to have optimized this call > (adding the buffer results in no measurable speedup in the sun JDK), so I > think we can expect unoptimized user code to become more widespread, and > there is probably a (albeit probably less dramatic) payoff for other code. AFAICS, the best solution would probably be to have an own private (and final) implementation for a direct byte buffer, and let the jikesrvm compiler replace calls to this implementation with direct memory accesses. For non-direct byte buffers something similar could be done. I'm not a big fan of having a VM layer here, as the API is abstracted out anyway already. I don't know if the FileInputStream should attempt to use a direct buffer. I guess it could be better in the case when a VM supports efficient access to it (see above). In other cases it should not be slower, so we should probably try to use direct buffers there (and in other places like the InputStreamReader). BTW, does Xalan make use of InputStreamReader and OutputStreamWriter too? Then you might want to try out my patches on these classes that are hanging in the review-queue for a while already. I'll post an update to them soon, as I have some more improvements here. Cheers, Roman
