Withdrawn: 8292914: Introduce a system property that enables stable names for lambda proxy classes

[duke]

On Thu, 25 Aug 2022 14:32:06 GMT, Strahinja Stanojevic <duke at openjdk.org> wrote:

> This PR introduces an option to output stable names for the lambda classes in the JDK. A stable name consists of two parts: The first part is the predefined value `$$Lambda$` appended to the lambda capturing class, and the second is a 64-bit hash part of the name. Thus, it looks like `lambdaCapturingClass$$Lambda$hashValue`.
> Parameters used to create a stable hash are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During this process, all the mutual parameters are in the same form as they are in the low-level implementation (`SystemDictionaryShared::add_lambda_proxy_class`) of the archiving process.
> We decided to use a well-specified `CRC32` algorithm from the standard Java library. We created two 32-bit hashes from the parameters used to create stable names. Then, we combined those two 32-bit hashes into one 64-bit hash value.
> We chose `CRC32` because it is a well-specified hash function, and we don't need to write additional code in the JDK. `SHA-256, MD5`, and all other hash functions that rely on `MessageDigest` use lambdas in the implementation, so they are unsuitable for our purpose. We also considered a few different hash functions with a low collision rate. All these functions would require at least 100 lines of additional code in the JDK. The best alternative we found is 64-bit` MurmurHash2`: https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash2.java.html.  In case adding a new hash implementation (e.g., Murmur2) to the JDK is preferred, this PR can be easily modified.
> We found the post (https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed/145633#145633) that compares different hash functions.
> We also tested the `CRC32` hash function against half a billion generated strings, and there were no collisions. Note that the capturing-class name is also part of the lambda class name, so the potential collisions can only appear in a single class. Thus, we do not expect to have name collisions due to a relatively low number of lambdas per class. Every tool that uses this feature should handle potential collisions on its own.  
> We found an overall approximation of the collision rate too. You can find it here: https://preshing.com/20110504/hash-collision-probabilities/.
> 
> JDK currently adds an atomic integer after `$$Lambda$`, and the names of the lambdas depend on the creation order. In the `Test...

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10024