On Thu, 10 Mar 2022 12:11:06 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> The "heap dump" aspect of this is not something I'm familiar with, but if >> the threads don't affect the list of classes dumped, they surely must affect >> what is in the heap dump otherwise their execution would not be an issue. So >> you must be sacrificing something by not having these threads start. > > @dholmes-ora That something is "sacrificed" does not follow from that > something is "different". The list of classes to dump is specified in the > lib/classlist file, which is generated during the build. > > The process of creating this involves running a suitable "exercise most > important parts" java program, and logging the classes loaded. This class > file is then post-processed (sorted) to make sure it is reproducible for the > same JDK code base. > > As Ioi say, in this case threads are started freely, and may run in any > non-deterministic order. > > At the next stage, we take this file (which is just done implicitly by > -Xshare:dump), and generate the actual CDS archive, classes.jsa. Now it turns > out this generation is non-deterministic. And Ioi's analysis is that this is > due to thread non-determinism. So if we just disable threads during the dump > process (where we are not really running the JVM "actually" -- it's a special > mode, where we don't even have a Java program to run!), there's no harm in > that. @magicus the issue is not the list of classes dumped, or their format in the dump. As Ioi indicated that list is fixed. The issue is with the heap dump part of the archive. Running these other threads affects the heap so by not running them with end up with a different heap. So the question is whether there is anything about having a different heap dumped that we need to be concerned about. We dump the heap into the archive for a reason and this changes what we dump, ------------- PR: https://git.openjdk.java.net/jdk/pull/7748
