<div dir="ltr"><div>Hi,</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>What do you think? Would it make sense to consider adding a field to JCTree to store end positions, instead of using EndPosTable?</div><div><br></div><div>I have a draft PR of the approach here: <a href="https://github.com/openjdk/jdk/pull/28506">https://github.com/openjdk/jdk/pull/28506</a></div><div><br></div><div>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: <a href="https://clang.llvm.org/diagnostics.html">https://clang.llvm.org/diagnostics.html</a></div></div>