> 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 <[email protected]> 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 >
