RFR: 8264413: Data is written to file header even if its CRC32 was calculated [v4]

Calvin Cheung ccheung at openjdk.java.net
Wed Mar 31 16:03:24 UTC 2021


On Wed, 31 Mar 2021 03:20:53 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Many tests under `runtime/cds/appcds/dynamicArchive` are crashed when turning on VerifySharedSpaces, VM reports inconsistent crc32 between dumptime and runtime(See detailed content on JBS attachments):
>> 
>> $ diff dump.log run.log
>> 17c17
>> < - base_archive_is_default:        0
>> ---
>>> - base_archive_is_default:        1
>> 19c19
>> < - base_archive_name_size:         0
>> ---
>>> - base_archive_name_size:         113
>> 
>> The root cause is that even if the CRC32 is calculated(Line 1902), ArchiveBuilder is still writing data to FileMapInfo(Line 1903):
>> 
>> https://github.com/openjdk/jdk/blob/4ea6abfbd1818fa7049bc4f6e46d568e842acb34/src/hotspot/share/memory/archiveBuilder.cpp#L1091-L1094
>> 
>> https://github.com/openjdk/jdk/blob/4ea6abfbd1818fa7049bc4f6e46d568e842acb34/src/hotspot/share/memory/filemap.cpp#L1236-L1251
>> 
>> Now the expected CRC32(serialized in CDS archive) is different from the calculated ones at runtime. This patch addresses this problem, it writes base_archive_name and size into header **before** calculating CRC32(if needed).
>> 
>> Thanks~
>> Yang
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add new jtreg test with VerifySharedSpaces

Marked as reviewed by ccheung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3261


More information about the hotspot-runtime-dev mailing list