On Wed, 14 May 2025 03:55:22 GMT, David Holmes <dhol...@openjdk.org> wrote:
> But given you state that CDS is a subset of AOT - the AOT for metaspace - > does it really make sense to simply rebadge "cds" logging as "aot"? It seems > to me that "aot" logging will generate massive amounts of data if everything > AOT related logs when "aot" is used. Would you not want finer-grained logging > such that "cds" becomes "aot+metaspace" as described? Many "cds" logs already have sub-levels. E.g., `[cds][heap]`, `[cds][module]`. The top-level `[cds]` log are used for general trouble shooting (e.g, the CDS archive cannot be mapped). Today, if you run with -Xlog:cds, there's a fair amount of logs but not massive: $ java -Xlog:cds --version [0.003s][info][cds] trying to map /jdk3/bld/tin/images/jdk/lib/server/classes.jsa [0.003s][info][cds] Opened shared archive file /jdk3/bld/tin/images/jdk/lib/server/classes.jsa. [0.003s][info][cds] The shared archive file was created with UseCompressedOops = 1, UseCompressedClassPointers = 1, UseCompactObjectHeaders = 0 [0.003s][info][cds] Core region alignment: 4096 [0.003s][info][cds] ArchiveRelocationMode: 1 [0.003s][info][cds] ArchiveRelocationMode == 1: always map archive(s) at an alternative address [0.003s][info][cds] Try to map archive(s) at an alternative address [0.003s][info][cds] Reserved archive_space_rs [0x000073d7fa000000 - 0x000073d7fb000000] (16777216) bytes (includes protection zone) [0.003s][info][cds] Reserved class_space_rs [0x000073d7fb000000 - 0x000073d83b000000] (1073741824) bytes [0.003s][info][cds] Mapped static region #0 at base 0x000073d7fa001000 top 0x000073d7fa48b000 (ReadWrite) [0.003s][info][cds] Mapped static region #1 at base 0x000073d7fa48b000 top 0x000073d7fad37000 (ReadOnly) [0.003s][info][cds] Mapped static region #2 at base 0x000073d88b5ce000 top 0x000073d88b600000 (Bitmap) [0.005s][info][cds] archived module property jdk.module.main: (null) [0.005s][info][cds] archived module property jdk.module.addexports: (null) [0.005s][info][cds] archived module property jdk.module.addmods: (null) [0.005s][info][cds] archived module property jdk.module.enable.native.access: (null) [0.005s][info][cds] archived module property jdk.module.addopens: (null) [0.005s][info][cds] optimized module handling: enabled [0.005s][info][cds] full module graph: enabled [0.005s][info][cds] CDS archive was created with max heap size = 128M, and the following configuration: [0.005s][info][cds] narrow_klass_base at mapping start address, narrow_klass_pointer_bits = 32, narrow_klass_shift = 0 [0.005s][info][cds] narrow_oop_mode = 0, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 0 [0.005s][info][cds] The current max heap size = 15488M, G1HeapRegion::GrainBytes = 8388608 [0.005s][info][cds] narrow_klass_base = 0x000073d7fa000000, arrow_klass_pointer_bits = 32, narrow_klass_shift = 0 [0.005s][info][cds] narrow_oop_mode = 1, narrow_oop_base = 0x0000000000000000, narrow_oop_shift = 3 [0.005s][info][cds] heap range = [0x0000000438000000 - 0x0000000800000000] [0.005s][info][cds] Preferred address to map heap data (to avoid relocation) is 0x00000000ffe00000 [0.005s][info][cds] Heap data mapped at 0x00000007ff800000, size = 1157176 bytes [0.005s][info][cds] CDS heap data relocation delta = 30058479616 bytes [0.005s][info][cds] use_full_module_graph = true; java.base = 0x000073d7fa4860a8 [0.005s][info][cds] patching heap embedded pointers: narrowOop 0xffe00000 -> 0xfff00000 [0.005s][info][cds] CDS heap data quick relocation not possible [0.005s][info][cds] Unmapping region #2 at base 0x000073d88b5ce000 (Bitmap) Going forward, we may change some of the logs to add an extra level if it makes sense. At this point, I don't see any logs that need immediate attention: $ java -Xlog:logging=debug [....] [0.009s][debug][logging] Available tag sets: , aot, aot+class, aot+codecache, aot+codecache+exit, aot+codecache+init, aot+codecache+reloc, aot+codecache+stringtable, aot+codecache+stubs, aot+hashtables, aot+heap, aot+heap+mirror, aot+init, aot+jvmti, aot+lambda, aot+link, aot+load, aot+mirror, aot+ref, aot+reloc, aot+unshareable, arguments, attach, cds, cds+class, cds+dynamic, cds+hashtables, cds+init, cds+lambda, cds+map, cds+map+oops, cds+module, cds+reloc, cds+resolve, cds+verification, cds+vtables, > I'm undecided whether this aspect of the work requires a CSR request ... but > it never hurts to have one. Obviously in 26 there will be one for the actual > deprecation/obsoletion/expiration process. Since most of the logs are for diagnostic purposes and are often changed along with the VM code, I think it's not necessary for a CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25136#issuecomment-2880887150
