> Hi, > >> [snip] >> >> > 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. >> >> Yep, we have our own DirectByteBufferImpl class. The problem is that >> with >> the code base as it stands, arranging for a DirectByteBuffer to be >> allocated is a bit clumsy. To quote from ByteBuffer.java, >> >> // FIXME: In GCJ and other implementations where arrays may not >> // move we might consider, at least when offset==0: >> // return new DirectByteBufferImpl(array, >> // address_of_data(array) + offset, >> // length, length, 0, false); >> // This may be more efficient, mainly because we can then use the >> // same logic for all ByteBuffers. >> >> [snip] > > Hmm. I guess I don't know enough about the internals of JikesRVM. Can > arrays move there? JikesRVM has a range of memory managers. The most extreme in one sense are the SemiSpace and GenCopy collectors, where all objects smaller than 8k move. The 'production' collector is GenMS, where objects smaller than 8k are allocated in a nursery and copied to a non-moving mature space. So in general with the default BufferedReader/Writer buffer size of 512 bytes the first few hundred IO operations on a given channel probably take place through a moveable buffer, which is then copied (if the file is open long enough) and thereafter becomes immovable. One optimization I would like to pursue is some kind of analysis in the JIT compiler that would identify the allocation sites of IO buffers and allocate them directly into a non-moving space. >> > 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. >> >> No, it doesn't use them. > > I find that surprising, especially because XML is supposed to support a > bunch of encodings. Perhaps I should be clearer - xalan the package has a range of input and output methods, some of which layer on StreamReader/Writer classes. DaCapo xalan the benchmark takes input via a FileInputStream directly to a xalan StreamSource class, and doesn't use these classes. cheers
