Any major performance change with I/O from JDK 6 that one should be aware of?
Alan Bateman
Alan.Bateman at oracle.com
Sun May 13 13:24:04 PDT 2012
On 13/05/2012 20:34, Fabrizio Giudici wrote:
>
> I think MD5 would lead to a higher CPU usage. In any case, I'm
> isolating a test case only focused on I/O. I'm creating 20 files whose
> size ranges from 10 to 100 MB and run the above code on it. Files are
> created from scratch at each run to avoid disk caching issues.
> Performance measures are:
>
> * for Apple JDK 6: speed 78-88 MB/sec
> * for OpenJDK 7: speed 518-716 MB/sec
>
> The latter figure is clearly a fake one: in fact the system monitor
> sees no disk activity. Is it possible that the MapByteBuffer.load()
> method changed behaviour, postponing the actual data loading? It would
> be compatible with the specs:
>
> ****
> Loads this buffer's content into physical memory.
> This method makes a best effort to ensure that, when it returns, this
> buffer's content is resident in physical memory. Invoking this method
> may cause some number of page faults and I/O operations to occur.
> ****
>
>
> Perhaps JDK 6 loads everything with the single load() call, which is
> more efficient, while OpenJDK 7 postpones it? And perhaps it does it
> inefficiently due to a scattered data access by means of the MD5
> library? (I knew a lot about crypto algorithms time ago, but now I've
> forgotten all the details).
>
The load method working by touching each page to bring it into memory.
The only difference in this regard between jdk6 and 7 is that it was
done in native code in jdk6 whereas it's in Java code in jdk7 (the
reason for this was to be able to recover with mapped files that get
truncated). Performance-wise it shouldn't make a difference and most of
the time should be paging in the file. From your figures above it would
appear that it's not touching all pages but it requires digging into the
details to track this down (plus I would point out that we have no idea
if anything was changed in this area in Apple's JDK6). In any case, can
you submit a bug on this?
-Alan
More information about the macosx-port-dev
mailing list