On Wed, 4 Nov 2026 10:02:44 GMT, Alan Bateman <[email protected]> wrote:
>> src/java.base/share/classes/java/io/RandomAccessFile.java line 1043:
>>
>>> 1041: boolean endOfFile = false;
>>> 1042: try {
>>> 1043: while (!eol) {
>>
>> The new code incurs JFR-related bookkeeping (i.e., `endOfFile` and
>> `bytesRead` updates) and `try`/`finally` costs even when `!jfrTracing`. Has
>> it been verified (via JMH?) that these extra costs when JFR is inactive are
>> indeed negligible? Presumably `RAF::readLine` can get very hot in a typical
>> application.
>
> The event is enabled by default and probably rare to disable. Measuring would
> be good but typically it's the file I/O that dominates. RAF is for random
> read/write access, code doing sequential access and reading lines is more
> likely to be using something else.
I ran JMH with JFR disabled using a 1000 lines file with lines that have 1, 10
or 100 characters. There is virtually no difference.
Separate method:
Benchmark (characters) Mode Cnt Score Error
Units
RandomAccessFileReadLine.readLine 1 avgt 15 722.808 ± 5.538
ns/op
RandomAccessFileReadLine.readLine 10 avgt 15 3900.799 ± 49.158
ns/op
RandomAccessFileReadLine.readLine 100 avgt 15 35504.408 ± 190.431
ns/op
Merged method:
Benchmark (characters) Mode Cnt Score Error
Units
RandomAccessFileReadLine.readLine 1 avgt 15 730.522 ± 16.693
ns/op
RandomAccessFileReadLine.readLine 10 avgt 15 3910.808 ± 45.717
ns/op
RandomAccessFileReadLine.readLine 100 avgt 15 35506.157 ± 135.345
ns/op
The difference when JFR is enabled can be ignored. Users have opted in and
taking two timestamps will dominate the cost.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33637#discussion_r4466645171
