RFR: JDK-8188312 Use CDS if present when running the Boot JDK during build (original) (raw)

Erik Joelsson erik.joelsson at oracle.com
Tue Oct 10 10:51:52 UTC 2017

Looks good. This seems to cover all relevant situations.

/Erik

On 2017-10-06 11:04, Magnus Ihse Bursie wrote:

On 2017-10-05 18:08, Ioi Lam wrote:

On 10/5/17 2:35 AM, Magnus Ihse Bursie wrote: On 2017-10-05 11:07, Claes Redestad wrote:

On 2017-10-05 10:59, Magnus Ihse Bursie wrote: How often is -Xbootclasspath/p used? Why not use "-XX:-VerifySharedSpaces -XX:SharedArchiveFile=local.jsa -Xshare:auto"? That way you will have the start-up benefit if possible. My worry here is that -Xshare:auto will not work correctly if -Xbootclasspath/p is used. Maybe someone can guarantee that this will work and convince me that it will never fail, but I don't think this risk is worth the marginal gain. Using -Xshare:auto should mean any case where a CDS archive can't be used (for whatever reason) should be silently ignored. I'd be more worried if -Xshare:on didn't fail in this case! But we're actively disabling verification of the CDS archive! How is then CDS supposed to know that it contains code for core classes that has been superseded using -Xbootclasspath/p? Hi Magnus, Now I understand your hesitation -- sorry the docs aren't clear about how the CDS archive is validated. + The classpath validation is always done, and cannot be turned off. So if -Xbootclasspath/p is used, the CDS archive will not be loaded. And the error messsage about incorrect class paths when i used -Xshare:on, was it the way CDS tells me it will not use the CDS archive due to -Xbootclasspath/p? + After the CDS archive is loaded, we have a second step that does a checksum over its contents. This step can be disabled using -XX:-VerifySharedSpaces In fact, -Xshare:auto has been the default for the client VM for many JDK releases, and we have not had any issues. (JDK-8188105 will make -Xshare:auto the default for server VM as well.) So, it's safe to use the combination of "-XX:-VerifySharedSpaces -XX:SharedArchiveFile=local.jsa -Xshare:auto" Okay. I'll make a fourth try: http://cr.openjdk.java.net/~ihse/JDK-8188312-use-CDS-for-bootjdk/webrev.04 Changes compared to previous: * I do not check if the local archive is present, I always re-generate it (Erik's concern about switching boot jdk) * If I cannot use the local archive, I always try adding -Xshare:auto anyway (Claes concern) * If I can use local archive, I use -Xshare:auto instead of -Xshare:on (which, according to the discussion above, should skip the use of the CDS archive when -Xbootclasspath/p is used). * Finally I renamed the variable to BOOTJDKUSELOCALCDS to clarify it's use. I'm currently running tests on this to see that it does not break. /Magnus Thanks - Ioi

This was supposed to be a quick and simple patch to get a small, but useful improvement. It's not worth a lot of investigation or fixes, imho. Repeating my suggestion I put as a comment in the RFE: add -Xshare:auto but leave out the code to dump an archive in the build (for now), so that those of us who prepare our boot JDK to have CDS archive generated can get the benefit from it. Well then, can you then guarantee that this will not break when replacing stuff using -Xbootclasspath/p? Because I don't want to be debugging things when a slightly different version of the class was not used as it should since an old cached version in CDS was picked up instead. :-( /Magnus /Claes

More information about the build-dev mailing list