RFR: JDK-8188312 Use CDS if present when running the Boot JDK during build

Ioi Lam ioi.lam at oracle.com
Thu Oct 5 16:08:37 UTC 2017

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.

+ After the CDS archive is loaded, we have a second step that does a 
checksum over its contents. This step can be disabled using 

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"

- 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