End position storage in javac

[Liam Miller-Cushon]

Hi,

I wanted to discuss how javac handles end positions, and get input on the
possibility of having the compiler unconditionally store end positions in a
field on JCTree instead of in a separate map.

Currently end position information is not stored by default, but is enabled
in certain modes: if -Xjcov is set, or if the compilation includes
diagnostic listeners, task listeners, or annotation processors (since they
may want end positions).

The hash table used to store the end positions was optimized in JDK 9
in JDK-8033287, and there was some related discussion on compiler-dev@
about the motivation for making end positions optional at that time.

As I understand it, the goal is to save memory in the case where end
positions aren't needed. That savings comes with a trade-off when end
positions are needed, though, since the map is less efficient than storing
the position directly in JCTree.

Today, many invocations of javac will need end position information
(annotation processing is common, when javac is used programatically in
IDEs end positions will be enabled). For the invocations that do not need
end positions, typical developer machines are less memory constrained than
they were when the optimization for end positions was first introduced.

Looking at the compilation of java.base, it contains about 3000 files and
creates about 3 million AST nodes, so adding an int field to JCTree to
store end positions would take about 12MB.

What do you think? Would it make sense to consider adding a field to JCTree
to store end positions, instead of using EndPosTable?

I have a draft PR of the approach here:
https://github.com/openjdk/jdk/pull/28506

Having end position information always available might enable some
potential improvements to javac. For example, some compilers indicate a
span of source text for some diagnostics, for example the 'range
highlighting' described in these clang docs:
https://clang.llvm.org/diagnostics.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251126/88fa84b1/attachment.htm>