Why is Kuromoji tokenization throughput bimodal? [LUCENE-9457]

With the recent accidental regression of Japanese (Kuromoji) tokenization throughput due to exciting FST optimizations, we [added new nightly Lucene benchmarks](https://github.com/mikemccand/luceneutil/issues/64) to measure tokenization throughput for `JapaneseTokenizer`: 

It has already been running for \_{5-6 weeks now!  But for some reason, it looks bi-modal?  "Normally" it is \}.45 M tokens/sec, but for two data points it dropped down to \~.33 M tokens/sec, which is odd.  It could be hotspot noise maybe?  But would be good to get to the root cause and fix it if possible.

Hotspot noise that randomly steals \~27% of your tokenization throughput is no good!!

Or does anyone have any other ideas of what could be bi-modal in Kuromoji?  I don't think [this performance test](https://github.com/mikemccand/luceneutil/blob/master/src/main/perf/TestAnalyzerPerf.java) has any randomness in it...

---
Migrated from [LUCENE-9457](https://issues.apache.org/jira/browse/LUCENE-9457) by Michael McCandless (@mikemccand), updated Aug 15 2020

Start with the nightly Kuromoji JapaneseTokenizer throughput benchmarks and inspect luceneutil/src/main/perf/TestAnalyzerPerf.java for possible sources of variation. Compare the normal and lower-throughput data points to determine why performance is bimodal. Done means identifying the cause and fixing it so tokenization throughput is stable.

Written by the indexing model from the issue text.