On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang <[email protected]> wrote:
>> LF editor spins classes, this avoids the spinning overhead and should speed
>> up non-capturing lambdas too.
>>
>> There may need to be additional intrinsic work for MH combinator lf bytecode
>> generation.
>
> Chen Liang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> We no longer load DelegateMH as we no longer rebind
src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1658:
> 1656: var carrier = argument(0, L_TYPE).withConstraint(species); //
> BMH bound with data
> 1657: Name[] constNames = new Name[] { carrier, new
> Name(species.getterFunction(0), carrier) };
> 1658: return LF_constant[type.ordinal()] = create(1, constNames,
> Kind.CONSTANT);
I think this caching logic should be in `constantForm`, which also does the
cache lookup.
src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 972:
> 970: callFilter = null;
> 971: else
> 972: callFilter = new Name(LambdaForm.identity(newType),
> newType.btWrapper.zero());
Maybe we could have a `Name` constructor that just takes an `Object` and
returns it like this.
test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestDynamicRegenerateHolderClasses.java
line 42:
> 40: static String CHECK_MESSAGES[] = {"java.lang.invoke.Invokers$Holder
> source: shared objects file (top)",
> 41:
> "java.lang.invoke.DirectMethodHandle$Holder source: shared objects file
> (top)",
> 42:
> "java.lang.invoke.DelegatingMethodHandle$Holder source: shared objects file
> (top)",
I don't understand why this change is needed. Could you please explain it?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1979282388
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1979441441
PR Review Comment: https://git.openjdk.org/jdk/pull/23706#discussion_r1979454377
