RFR(XS) 8234196 [TESTBUG] DynamicArchiveRelocationTest.java missing "ArchiveRelocationMode == 1 ...."

[Ioi Lam]

On 11/14/19 2:06 PM, Daniel D. Daugherty wrote:
> On 11/14/19 4:53 PM, Ioi Lam wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8234196
>> http://cr.openjdk.java.net/~iklam/jdk14/8234196-missing-relocation-mode-log.v01/ 
>>
>
> test/hotspot/jtreg/runtime/cds/appcds/ArchiveRelocationTest.java
>     No comments.
>
> test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicArchiveRelocationTest.java 
>
>     No comments.
>
> Thumbs up.
>
> I presume you've done a sanity check run on the two tests locally.
>
> Dan
>

Hi Dan,

Thanks for the review. Yes, I've done a sanity run locally. However, the 
original failure only happens infrequently on Windows and might be 
host-specific, so I wasn't able to reproduce the failure.


 From looking at the log file of the failed test run, I can see the 
"runtime archive relocation start" and "runtime archive relocation done" 
logs, so I think the fix should be correct (famous last words ...).

Thanks
- Ioi

>
>
>
>>
>> To ensure that archive relocation has happened, the test checks for 
>> the log message "ArchiveRelocationMode == 1: always map archive(s) at 
>> an alternative address". However, in debug builds, this message 
>> occurs ONLY if the archive has been successfully mapped at the 
>> desired location (after which the JVM will unmap the archive, and 
>> remap it at an alternative location). See
>>
>> http://hg.openjdk.java.net/jdk/jdk/file/b987ea528c21/src/hotspot/share/memory/filemap.cpp#l1397 
>>
>>
>> In this particular test run, the archive failed to be mapped at the 
>> designed location (this is quite common on Windows), so we never 
>> execute the line at filemap.cpp:1397. Hence the expected message was 
>> not printed.
>>
>> Anyway, the test cases already checks for the following messages:
>>
>>         "runtime archive relocation start";
>>         "runtime archive relocation done"
>>
>> so the check for "ArchiveRelocationMode == 1: ..." is redundant and 
>> can be removed.
>>
>> Thanks
>> - Ioi
>>
>