RFR: 8199807 & 8202738: AppCDS performs overly restrictive path matching check

[Magnus Ihse Bursie]

On 2018-05-11 23:33, Erik Joelsson wrote:
> Hello,
>
> For the build change, it's very undesirable to always have to relink 
> libjvm on every incremental build. Such a change cannot be accepted.
>
> I have a counter suggestion, which is still a bit of a hack, but it 
> will cause vm_version.cpp to be recompiled (almost) every time 
> libjvm.so needs to be relinked. The drawback is that compiling 
> vm_version.cpp is now bound to happen absolutely last and so cannot 
> happen in parallel with other compilations.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8202738/webrev.01/index.html

This looks as good as it can get for a simple fix, but I'd still like to 
get on the record that I think the way we handle both __TIME__/__DATE__ 
in hotspot, and ad-hoc version strings in general, is broken and leave 
much to be desired.

/Magnus



>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202738
>
> /Erik
>
>
> On 2018-05-10 16:11, Jiangli Zhou wrote:
>> Hi,
>>
>> Please review the following webrev that addresses the issue of 
>> copied/moved JDK image after generating a CDS archive. Thanks Karen 
>> Kinnear and Alan Baterman for initiating the investigation & 
>> discussions in this area (especially the ease of usage). Thanks Ioi 
>> for implementing a test case for moved JDK (JDK-8202935).
>>
>> webrev: http://cr.openjdk.java.net/~jiangli/8199807_8202738/webrev.00/
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8199807?filter=14921
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202738?filter=14921
>>
>> The webrev includes the following three main parts:
>>
>> 1. Reduced check for JDK ‘modules’ image file at runtime. The runtime 
>> path to the ‘modules’ image is no longer required to the the same as 
>> dump time path. Runtime performs file size check only for the 
>> ‘modules’ image, which must match with the dump time ‘modules’ size. 
>> Invalidation of an outdated archive is achieved by the existing 
>> vm_version string check (the archived vm_version string must match 
>> with the runtime vm_version string).
>>
>> 2. Boot path check are now performed based on the content of the 
>> archive. Also added a new test case in BootClassPathMismatch.java and 
>> add more comments for existing test cases.
>>
>> 3. Fixed the stale vm_version string issue with incremental build. 
>> The issue was discovered during the work of 8199807. CDS uses 
>> vm_version string as part of the runtime validation check for 
>> archive. A stale vm_version string causes the CDS runtime to 
>> mistakenly accept an outdated archive. The fix is to make sure 
>> vm_version.o is recompiled properly when the library/vm is rebuilt.
>>
>> Tested with hs-tier1-4 and jdk-tier1-2. Tested by relocating the JDK 
>> image manually after generating an archive. Also tested with Ioi’s 
>> test both locally and via Mach5.
>>
>> Thanks,
>> Jiangli
>>
>