On Fri, 17 Feb 2023 17:02:56 GMT, David M. Lloyd <d...@openjdk.org> wrote:
>> The class generated for lambda proxies is now defined as a hidden class. >> This means that the counter, which was used to ensure a unique class name >> and avoid clashes, is now redundant. In addition to performing redundant >> work, this also impacts build reproducibility for native image generators >> which might already have a strategy to cope with hidden classes but cannot >> cope with indeterminate definition order for lambda proxy classes. >> >> This solves JDK-8292914 by making lambda proxy names always be stable >> without any configuration needed. This would also replace #10024. > > David M. Lloyd has updated the pull request incrementally with one additional > commit since the last revision: > > Updated to use hidden class suffix for dumps when possible, else use the > counter with a `failed` suffix. Also, remove the extra trailing `$` from the > lambda class name and update tests accordingly. > > This combines the suggestions made by @mlchung and @ExE-Boss and hopefully > will resolve the Windows testing issue. On 2/17/2023 12:50 PM, Ioi Lam wrote: > > If you really want a stable name, an alternative approach is to walk > the stack and find the caller of |LambdaMetafactory.metafactory| and > get the constant pool index of the invokedynamic instruction. (This > probably needs to be done with a native method). > > Javac uses a unique CP index for each call site (15 vs 23 in the > following example). > This is actually no longer true. Liam @ Google did a "lambda deduplication" where multiple identical lambdas in a compilation unit are folded to a single index in the BSM, which can be used by multiple capturing indys. ------------- PR: https://git.openjdk.org/jdk/pull/12579
