On 2017-10-05 11:35, Magnus Ihse Bursie wrote:
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?
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. :-(
I was not suggesting adding -XX:-VerifySharedSpaces - Ioi can probably
tell if disabling this verification could lead to a corrupt heap state
in presence of -Xbootclasspath/p.
I think -Xshare:auto alone is safe no matter what.
/Claes
