RFR: 8316493: Make immutable maps @ValueBased [v3]

[Chen Liang]

On Thu, 21 Sep 2023 16:40:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
>> 
>> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
>> 
>> We need to benchmark this solution to better understand its implications.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into vb-map2
>  - Remove redundant impl spec parts
>  - Merge pull request #4 from cl4es/HashMapViews
>    
>    Add simple HashMapViews microbenchmark
>  - Add simple HashMapViews microbenchmark
>  - Remove caching in AbstractMap and make immutable maps @ValueBased

For compatibility, the alternative is arguably dangerous too: Users could cast the factories map to AbstractMap, a public type, before, and that may be another impl detail that they accidentally depend on. And legacy user immutable maps may have a harder time migrating to be value classes.

For the current approach, I think this allows existing AbstractMap-based implememtations to go value, which is a great benefit. The risk from the 2 method usages are actually less worrying considering that any subclass that overrides either method will have no compatibility risk. The bigger risk lies in behavioral changes in JDK's builtin Maps' two methods' implementation (loss of caching): I anticipate many more users to actually use than implement maps. Another less pronounced risk is users reflecting on the 2 fields, which arguably is low impact for they are technically implementation details.

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

PR Comment: https://git.openjdk.org/jdk/pull/15614#issuecomment-1731246046