Re: VMChannel read/write native interface

On Jan 28, 2007, at 12:15 AM, Robin Garner wrote: 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 n

Re: VMChannel read/write native interface

> 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 s

RE: VMChannel read/write native interface

Hi, Am Sonntag, den 28.01.2007, 10:20 +0100 schrieb Jeroen Frijters: > Roman Kennke wrote: > > 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 n

RE: VMChannel read/write native interface

Roman Kennke wrote: > 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

Re: VMChannel read/write native interface

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 > incarnatio