3

I recently noticed that Java/JDK is doing 8k small copy/IO in a few places. For example:

FileChannel.transferFrom.transferFromArbitraryChannel
ReadableByteChannelImpl.TRANSFER_SIZE

In my opinion, 8k is pretty small, especially doing 8k disk IO.

So, is there any reason that java/jdk use 8k? is there any way to override this value?

Thanks!

user2254473
  • 31
  • 2
  • Do you experience any downside of this limitation? If not then don't even bother yourself – Lino Jul 17 '18 at 19:22
  • 3
    I guess curiosity is banned – ifly6 Jul 17 '18 at 19:23
  • 3
    What value would you like? Why do you think 8k is small? – Boris the Spider Jul 17 '18 at 19:23
  • @ifly6 it's just not that type of question suited for SO, who do you think except the Java Devs could answer that question: *is there any reason that java/jdk use 8k*? – Lino Jul 17 '18 at 19:24
  • @Lino: Obviously, the one who has implemented the class, huh? – Nikolas Charalambidis Jul 17 '18 at 19:28
  • 1
    @Lino: It was a joke, tho. – Nikolas Charalambidis Jul 17 '18 at 19:31
  • 1
    @Nikolas whoops, the sarcasm has some difficulties to reach me, sorry ^^ – Lino Jul 17 '18 at 19:31
  • 3
    You're asking why the JDK developers for Java 1.1 *(in 1997, more than 20 years ago)* decided to use [8k as the default buffer size](https://github.com/fanhongtao/JDK/blob/jdk_1.1.3/src/java/io/BufferedReader.java#L72)? Likely because it was a good compromise between performance and memory footprint (back then). – Andreas Jul 17 '18 at 19:39
  • 2
    larger buffer sizes might not be faster as bigger buffers don't fit into the L1 cache. (both source and duplicate) – Peter Lawrey Jul 17 '18 at 19:46
  • Here's the problem: no matter what they chose / choose as the default, **someone** will think it is wrong. Or to put it another way, different use-cases would require different defaults ... if they relied on defaults. Deciding what the best default is requires people to assemble a large sample of *representative* applications, and *measure* the effect of changing the defaults. (And that includes indirect effects, such as examining the effects of larger memory footprints, increased GC rates, etcetera, that would result from a bigger default size.) – Stephen C Jul 17 '18 at 22:52
  • ... And note that the benchmarking needs to be done across a wide range of hardware and OS platforms, computer sizes, etc. Finally, Oracle almost certainly cannot change the default now because of the (real) risk that a change would cause old code that relies on the defaults to use too much memory on a new version of Java. Breaking old code is a big "no no", especially given Oracle's current strategy of de-supporting old Java releases. (Essentially, your opinion / my opinion / anyone but Oracle's opinion ... is moot!) – Stephen C Jul 17 '18 at 22:55
  • Thanks for the explanation. I agree with @Stephen C – user2254473 Jul 18 '18 at 19:48
  • 8K may be good for cache alinement, but if the target is disk and total size is > 1MB, it can invoke 1M/8K system call and generate small IOs, which I don't think is performance friendly. – user2254473 Jul 18 '18 at 19:50
  • @Lino I suspect bigger IO size is friendly to my implementation which request > 1MB data write to disk. – user2254473 Jul 18 '18 at 19:53

0 Answers0