LambdaFormInvokers::regenerate_holder_classes() calls the Java method jdk.internal.miscCDS::generateLambdaFormHolderClasses(), which returns information for two types of classes:

[1] Holders, which are the following four classes:

- java/lang/invoke/DelegatingMethodHandle$Holder
- java/lang/invoke/DirectMethodHandle$Holder
- java/lang/invoke/Invokers$Holder
- java/lang/invoke/LambdaForm$Holder

[2] Species. For example:

- java.lang.invoke.BoundMethodHandle$Species_IL
- java.lang.invoke.BoundMethodHandle$Species_FL
- ...

In this version:

https://github.com/openjdk/jdk/blob/eeb345a286115213f8a75dfe54cdcc39dfca597a/src/hotspot/share/cds/lambdaFormInvokers.cpp#L173

LambdaFormInvokers::regenerate_class() is called to regenerate each of these classes. For group [1], the regeneration is necessary: at this point, DelegatingMethodHandle$Holder has already been loaded by the VM, but we want to replace it with a new version (that has more methods).

However, for group [2], the regeneration is not necessary:

- The contents of a class like BoundMethodHandle$Species_IL are fixes. It's not affect by what classes are stored in the CDS archive.
- When miscCDS::generateLambdaFormHolderClasses() returns the name of a Species class, that class has already been loaded into the system dictionary (as a regular class in the boot loader).

So, there's no need to create a new version of the Species classes inside LambdaFormInvokers::regenerate_class(). However, in some cases, we do need to call Klass::set_regenerated() to indicate that this class was generated but we did not save the bytecodes.