RFR: 8351556: Optimize Location.locationFor/isModuleOrientedLocation [v2]

[Chen Liang]

On Mon, 10 Mar 2025 18:34:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Leyden's JavacBenchApp benchmarks shows ~1% of time of the very first iteration is spent doing `Pattern.compile` in `Location.isModuleOrientedLocation`. Additionally, `Pattern.compile` becomes hot and requires JIT compilation, which eats CPU time. We can do better.
>> 
>> This improvement naturally spills over to `Location.locationFor`.
>> 
>> Things we do:
>>  1. Avoid `putIfAbsent` on fast-path.
>>  2. Lazily cache `Pattern` and reuse for all related paths.
>>  3. Capture output/module flags ahead of time, instead of recomputing them.
>>  4. (for interpreter/startup benefit) Use direct class type instead of interface.
>> 
>> There is also a little matching bug ([JDK-8351561](https://bugs.openjdk.org/browse/JDK-8351561)), which this performance improvement would retain.
>> 
>> Additional testing:
>>  - [x] New regression test still works
>>  - [x] New benchmark shows improvements
>>  - [x] Linux x86_64 server fastdebug/release, `langtools_all`
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Also direct properties test
>  - Touchups

src/java.compiler/share/classes/javax/tools/StandardLocation.java line 119:

> 117:     private static final ConcurrentHashMap<String, Location> LOCATIONS = new ConcurrentHashMap<>();
> 118: 
> 119:     private static class LazyPatternHolder {

Should we keep this as a local class in `computeIsModuleOrientedLocation` as it is only used in that method??

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23973#discussion_r1987900168