RFR (XS) 8221918: runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java fails: Shared archive not found

[Jiangli Zhou]

Hi Aleksey,

Looks okay to me. This also addresses the issue for
ReplaceCriticalClassesForSubgraphs.java automatically. Theses tests intend
to check the interactions between JVMTI agent and CDS for shared classes
like Object, String, etc. The JVMTI interaction issue is not default CDS
archive only issue, it becomes more prominent with the enabling of the
default CDS archive. I'd suggest to dump the archive like the following and
also remove the '.setUseSystemArchive(true)' from the CDSOptions
in launchChild() (an archive generated in the JTwork/scratch is used in
this case). That would also help avoid any potential issue in case the
JDK's lib/ directory is read-only in some of the environments.

               CDSOptions opts = new CDSOptions()
                   .setXShareMode("dump")
                   .setUseVersion(false)
                   .addSuffix("-showversion");
               CDSTestUtils.createArchive(opts);

Thanks and regards,

Jiangli

On Wed, Apr 3, 2019 at 8:25 AM Aleksey Shipilev <shade at redhat.com> wrote:

> Test bug:
>   https://bugs.openjdk.java.net/browse/JDK-8221918
>
> Fix:
>   http://cr.openjdk.java.net/~shade/8221918/webrev.01/
>
> It seems the test is running with -Xshare:auto, which expects the CDS
> archive to be generated by
> default during the build? x86_32 fails with "Shared archive not found" in
> that test, and it fails
> tier1 then.
>
> Dumping the CDS archive before starting the test helps those configs where
> archive is not created
> automatically. I copy-pasted the new block from the test (later in the
> same file) and dropped some
> non-essentials.
>
> Testing: affected test on Linux {x86_64, x86_32} fastdebug, jdk-submit
> (running)
>
> --
> Thanks,
> -Aleksey
>
>
>