RFR: 8260053: Optimize Tokens' use of Names

[Maurizio Cimadamore]

On 20/01/2021 18:25, Jonathan Gibbons wrote:
> I realize why you need this, but this is a questionable import from an architectural point of view.   Spaghetti imports can be a problem, and the intent has been that `utils` is a collection of low-level utility classes, and the parser is a layer built on top of that:  here, you are adding a reverse dependence, so that a class in `utils` depends on a class in `parser`.

I tend to agree with Jon here. While it's clear what the intent is, 
creating an explicit coupling between Names (which is the global holder 
for all compiler names) and Tokens, by adding a coupling from the former 
to the latter, is smelly. What you want, in principle, is to setup some 
kind of map in TokenKind, so that, for each name, you know which token 
(if any) corresponds to that. What javac does right now is sub-optimal 
memory-wise (an array is created of which many buckets will be empty), 
but very efficient performance-wise (a lookup is just an array access).

Additional note: in all cases I could find, this lookup will take place 
from a Java String. Which means the following sequence takes place:

1. lookup from String to Name (names.fromString(String))
2. lookup from Name to Token

I wouldn't be surprised if replacing this infrastructure with a 
Map<String, Token> on Tokens will lead to similar performances to those 
we have now (but better memory utilization). E.g. we have to do a "slow" 
lookup anyway before being able to do the fast lookup.

Maurizio