Henning Andersen created LUCENE-9503:
----------------------------------------
Summary: Fix comment explaining reason for 8KB buffered/chunked
writes
Key: LUCENE-9503
URL: https://issues.apache.org/jira/browse/LUCENE-9503
Project: Lucene - Core
Issue Type: Improvement
Components: core/store
Affects Versions: 8.6.2
Reporter: Henning Andersen
Attachments: LUCENE-8kb-comment.patch
FSDirectory uses an 8KB buffer and chunk size when writing to disk. The class
has a comment explaining how file channels would do mallocs for larger chunks.
However, that comment was originally introduced when RandomAccessFile and later
FileOutputStream was used. Since the switch to file channels, there is no
longer any difference (except the size of the buffer) for different
buffer/chunk sizes.
Attached patch keeps the comment, clarifying that it is a historic reason.
Including my research here for background information in case this helps
validate the change:
# The stack buffer for 8KB or below in the JDK is here:
[https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjava/io_util.c#L150]
This is used by both {{FileOutputStream}} and {{RandomAccessFile}}.
# This was applicable when the comment to lucene was added and later changed
to {{FileOutputStream}}:
[https://github.com/apache/lucene-solr/commit/c4bdb2dad0abd85427f36732f4b1be66787b9815#diff-dc399b5658d57753fffdad7539f22e50R344]
# Lucene cut over to nio here:
[https://github.com/apache/lucene-solr/commit/3eb66fb19ca2aa3d9dce53661f3233b6c9d3f974#diff-dc399b5658d57753fffdad7539f22e50R324]
and the comment was later changed to say {{file channels}} here:
[https://github.com/apache/lucene-solr/commit/cf845b1335af05f27d746a38a043bd815821a69f]
# File channels use thread local direct buffers instead, see
sun.nio.ch.IOUtil.write, which uses Util.getTemporaryDirectBuffer to get a
thread local buffer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
