On Tue, 8 Feb 2022 16:49:41 GMT, Alex Menkov <amen...@openjdk.org> wrote:
> ClassLoaderDataGraph::classes_do description says:
> // Walking classes through the ClassLoaderDataGraph include array classes.
> So do_load_class callback should not dump arrays for the classes and dumper
> doesn't need to call Universe::basic_type_classes_do (array classes for
> primitive types are also reported by ClassLoaderDataGraph::classes_do)
test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line
58:
> 56: String[][][] strArray = new String[0][][];
> 57: LingeredApp.main(args);
> 58: System.out.println("" + intArray + strArray); // to be sure the
> classes are not unloaded
Use Reference.reachabilityFence(<array>);
test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line
86:
> 84: Process p = ProcessTools.startProcess("jcmd", new
> ProcessBuilder(launcher.getCommand()));
> 85: // If something goes wrong with heap dumping most likely
> we'll get crash of the target VM.
> 86: while (!p.waitFor(5, TimeUnit.SECONDS)) {
5 seconds seems kind of short. Doesn't allow for occasional network hiccups.
test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line
218:
> 216: }
> 217:
> 218: // Reads the whole HPROF_GC_CLASS_DUMP record, returns closs ID.
"class ID"
-------------
PR: https://git.openjdk.java.net/jdk/pull/7384
