Don't allocate a VisitorState when a memoized lookup hits the cache

[vlsi]

Why

VisitorState.Cache.get replaced the caller's state with a pathless copy before it looked in the cache:

public synchronized T get(VisitorState state) {
  state = state.withNoPathForMemoization();

  T value = cache.get();
  if (value == null) {
    value = impl.get(state);
    ...

The copy keeps a memoized supplier from reading a TreePath that belongs to one compilation unit while its result is cached for the whole compilation, so impl.get is the only caller that needs it. The cache answers most reads without calling impl, and those reads allocated a VisitorState and dropped it.

The scanner reaches memoized suppliers through TypePredicates, Suppliers.typeFromString, Matchers, and MethodMatchers, once per matcher per AST node, so the reads are frequent: compiling the 948 sources of error_prone_core with Error Prone enabled runs Cache.get 25448504 times and answers 17019874 of those from the cache.

What

compute now makes the pathless copy, and it runs only when the value has to be computed. withNoPathForMemoization returns this when the path is already null, so a memoized supplier that reads another memoized value allocates nothing either.

impl still receives a state whose getPath() throws, and the provenance bookkeeping reads sharedState, which the copy shares with the original.

How to verify

mvn -pl check_api,core test

Allocation was measured with an in-process javac compiling the 948 sources of error_prone_core with Error Prone enabled on JDK 24, reading ThreadMXBean.getThreadAllocatedBytes for the compiling thread. Steady state over six compilations in one JVM: 8.251 GiB before, 7.744 GiB after. The 17019874 cached reads at 32 bytes per VisitorState come to 0.507 GiB, which is the whole difference.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[cpovirk]

FWIW, an internal benchmark on com.google.common.collect doesn't show any improvement in wall time, CPU time, or peak memory. But things can be different when compiling different code and when compiling with different settings, and steady-state memory matters, too. This seems straightforward enough to be worth trying.