RFR: 8372948: Store end positions directly in JCTree

[Maurizio Cimadamore]

On Wed, 3 Dec 2025 09:44:44 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> 
> My feeling is that perhaps it's worth the extra memory to not have to duplicate that code for all of those `JCTree`s, and also to avoid the risk of trying to store end positions on trees that don't support it. But I am open to making those changes if there's a preference for it.

I tend to agree with your assessment. Having code duplication is kind of bad, unless we can somehow "common" the code -- and that's is probably possible, but not straightforward due the JCStatement vs. JCExpression split (and also JCFunctionalExpression).

Also, it's hard to estimate which trees might need this... for instance the trees you show in your analysis don't include some patterns (e.g. record patterns), but that's just because probably there's no record pattern in the JDK, not because the end pos is not useful there.

If we exclude JCSkip and maybe LetExpr (as that's only used by the backend), I'm not sure there's much stuff that actually doesn't require an end position? Perhaps with some keywords like `break`, `continue`, ... we might be able to infer the end pos (given it's just start pos + number of chars in the keyword). But not sure how much we are willing to bend the code for special cases like these?

One more interesting experiment could be to try to enable end position in all trees, then run the JDK build and compare with mainline, to see what the memory usage looks like (maybe enabling `-verbose:gc` and looking where it peaks).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3608408811