RFR: 8372948: Store end positions directly in JCTree

[Jonathan Gibbons]

> What tradeoffs do you see here, would only declaring the field on trees that need it be mostly about saving memory?

Probably, yes, as well as just being a closer equivalent to the existing code.

>Also is that unique to end positions? Or could javac potentially avoid storing start positions for nodes that don't start with a lexical token as well?

Every JCTree node already has a 'pos' field, representing the position of the first character that is unique to the tree node.  That means it is the 'start' position for those nodes that begin with a lexical token, and so no additional field is necessary.

The asymmetry between start and end positions is indicative of why there is only an EndPosTable, without any need for a StartPosTable.

-- Jon

On Tue, Dec 2, 2025, at 8:30 AM, Liam Miller-Cushon wrote:
> On Tue, 2 Dec 2025 16:21:21 GMT, Jonathan Gibbons <jjg3 at pobox.com> wrote:
> 
> > Without looking in detail at this specific proposal, I wonder if you considered the alternative to only store end positions in the subtypes of JCTree that actually "need" them. In other words, you only need store end positions in tree nodes that "end" in a lexical token and not in a child tree node. Effectively, you only need store the end position in tree nodes that would otherwise have entries in the EndPosTable.
> 
> Good question--I hadn't investigated that option. It seems do-able, perhaps with a shared interface for subtypes that needed end positions to simplify the handling of them.
> 
> What tradeoffs do you see here, would only declaring the field on trees that need it be mostly about saving memory?
> 
> Also is that unique to end positions? Or could javac potentially avoid storing start positions for nodes that don't start with a lexical token as well?
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3602921946
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251202/0d4fee58/attachment.htm>