On Fri, 10 May 2024 04:23:35 GMT, Ioi Lam <ik...@openjdk.org> wrote: >> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's >> LambdaForm method type parameters. Since they are distinct from those of >> Linkers, they are now tracked and generated separately. It seems that no >> proper invoker was ever generated before, except it happens that most >> invoker signatures can be taken as linker signature so we never detected it. >> >> Requesting @iklam for a review; since I don't know how to deal with CDS, I >> have to relay to someone else to ensure this fixes the problem from the CDS >> side as well. > > pinging @cl4es > > @liach, could you add a jtreg test case? I think you can use > https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/CDSLambdaInvoker.java
@iklam I have expanded the given case and it passes on my device locally. Since CDS doesn't have an easy way to find out the methods archived in a class, I resorted to enabling invoke's logging and checking the resolution output instead. Does this approach look good? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19164#issuecomment-2103859269
