[APPCDS] JDK-8236847: JDK built on machine with 4K pages refused to start on machine with 64k pages

[Ioi Lam]

Hi Dmitry,

I tried to simulate the scenario on x64 and I found out that the VM will 
continue to execute after printing out the "error" message, but with CDS 
disabled. Can you confirm that this is also the case in your environment?

I am working on a fix now (see proposed fix in the bug report).

Thanks
- Ioi

On 1/10/20 1:40 AM, Dmitry Samersoff wrote:
> Ioi,
>
>> 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.
> I use default parameters for java. i.e. ever simple
>
> java -version
>
> refuses to start with the message below.
>
>> 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.
> Typical scenario is:
>     We have AArch64 Jenkins build server with 4k pages that automatically
>
>        - builds JDK
>        - deploy it to a large server with 64k pages
>        - run set of tests
>            (regression and performance, not all of them are jtreg one)
>
> -Dmitry
>
>
>
>
> On 09.01.20 20:02, Ioi Lam wrote:
>>
>> 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
>>>>
>>>>
>>>>