RFR: 8276184: Exclude lambda proxy class from the CDS archive if its caller class is excluded

Calvin Cheung ccheung at openjdk.java.net
Mon Nov 15 18:19:20 UTC 2021


On Tue, 2 Nov 2021 05:57:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The proposed patch has been redone completely to address the problem when a caller class is being excluded
>> from the archive, the associated lambda proxy class(es) was not excluded.
>> 
>> The caller class could be excluded if:
>> - it is signed;
>> - it has been redefined after its lambda proxy class was created.
>
> FYI, I applied this patch and ran test/hotspot/jtreg/runtime/cds/appcds/SignedJar.java:
> 
> 
> $ git diff
> diff --git a/test/hotspot/jtreg/runtime/cds/appcds/test-classes/Hello.java b/test/hotspot/jtreg/runtime/cds/appcds/test-classes/Hello.java
> index 250a63adde8..f421ba5477f 100644
> --- a/test/hotspot/jtreg/runtime/cds/appcds/test-classes/Hello.java
> +++ b/test/hotspot/jtreg/runtime/cds/appcds/test-classes/Hello.java
> @@ -25,5 +25,10 @@
>  public class Hello {
>    public static void main(String args[]) {
>      System.out.println("Hello World");
> +    System.out.println(getRunnable());
> +  }
> +
> +  public static Runnable getRunnable() {
> +    return () -> {};
>    }
>  }
> 
> 
> Inside the JTREG scratch directory, you will find hello.jar and signed_hello.jar. The output of the second command seems suspicious. The Hello class is not archived, but its lambda proxy class is archived.
> 
> 
> $ java -cp hello.jar -XX:ArchiveClassesAtExit=foo.jsa -Xlog:cds+class=debug Hello | grep Hello
> Hello World
> Hello$$Lambda$1/0x0000000800c009f0 at 18b4aac2
> [0.144s][debug][cds,class] klasses[    1] = 0x0000000800bb4638 app   Hello$$Lambda$1/0x0000000800c009f0 ** hidden
> [0.144s][debug][cds,class] klasses[    2] = 0x0000000800bb49e0 app   Hello
> 
> $ java -cp signed_hello.jar -XX:ArchiveClassesAtExit=foo.jsa -Xlog:cds+class=debug Hello | grep Hello
> Hello World
> Hello$$Lambda$11/0x0000000800c011f0 at 5eb5c224
> [0.257s][warning][cds] Skipping Hello: Signed JAR
> [0.289s][debug  ][cds,class] klasses[  103] = 0x0000000800bea278 app   Hello$$Lambda$11/0x0000000800c011f0 ** hidden
> 
> 
> BTW, the above was executed using the product VM. Using fastdebug VM will produce the same assert as in JDK-8274944:
> 
> 
> $ fd -cp signed_hello.jar -XX:ArchiveClassesAtExit=foo.jsa -Xlog:cds+class=debug Hello 
> Hello World
> Hello$$Lambda$11/0x0000000801001200 at 6bf2d08e
> [0.848s][warning][cds] Skipping jdk/internal/event/X509CertificateEvent: JFR event class
> [0.848s][warning][cds] Skipping Hello: Signed JAR
> [0.848s][warning][cds] Skipping jdk/internal/event/X509CertificateEvent: Not in loaded state
> [0.848s][warning][cds] Skipping jdk/internal/event/Event: Not in loaded state
> [0.848s][warning][cds] Skipping jdk/internal/event/Event: JFR event class
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/archiveBuilder.hpp:293
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/jdk2/quo/open/src/hotspot/share/cds/archiveBuilder.hpp:293), pid=28770, tid=28777
> #  assert(is_in_buffer_space(obj)) failed: must be

@iklam I've pushed another update with the changes you suggested.
As we've discussed offline, the change also handles the case when an old interface/class is already in the base archive,
the interface/class should be considered verified during dump time. Therefore, we should also archive a class which
references the old interface/class in the base archive during dynamic dump.
Added 2 test cases for the above.

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

PR: https://git.openjdk.java.net/jdk/pull/6205


More information about the hotspot-runtime-dev mailing list