On 1/9/20 12:47 AM, David Holmes wrote:
On 9/01/2020 6:29 pm, Dmitry Samersoff wrote:
Hello Ioi,
*Story*
If you build JDK-14 with the changes for
JDK-8231610 Relocate the CDS archive if it cannot be mapped
to the requested address
on a machine with 4k pages (typical Jenkins machine) then move the
bundle to a huge server with 64k pages, it refuses to start with
[0.015s][error][cds] Unable to map CDS archive --
os::vm_allocation_granularity() expected: 4096 actual: 65536
*Question*
I'm not sure if just removing an assert is the correct fix. What would
you recommend?
I thought that failing to map the archive was a non-fatal error that
just results in falling back to not using CDS. Even in a debug build
this should not be an assertion unless perhaps the user has explicitly
requested CDS to be enabled.
Dmitry, are you running with -Xshare:on? If you use -Xshare:off (which
is the default), when the CDS archive cannot be mapped, the JVM will
continue execution.
Are you having problems running with the jtreg test cases? I can think
of a way to fix this, so that CDS can continue to work under this
circumstance, but I want to understand your scenarios more.
Thanks
- Ioi
Also @build-dev - is it possible to add configure option to disable
AppCDS archive generation?
Already there I think: --disable-cds-archive
Cheers,
David
-----
-Dmitry\S
