RFR: 8216427: ciMethodData::load_extra_data() does not always unpack the last entry

[Erik Osterlund]

Hi Vladimir,

Thanks for the review.

/Erik

> On 13 Jan 2019, at 23:11, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Looks good.
> 
> Please run hs-precheckin-comp too.
> 
> Thanks,
> Vladimir
> 
>> On 1/11/19 1:53 AM, Erik Österlund wrote:
>> Hi,
>> When unpacking the extra data section of the MDOs, the source and destination might not have the same number of entries, because there can be safepoints between cloning the extra data section of the MDO and unpacking the source entries to the destination entries.
>> Therefore the unpacking loop loops through all the source entries and copies them to the destination. Except the last DataLayout::arg_info_data_tag entry, that never gets copied form the source to the destination. Therefore, if a safepoint occurred between cloning the extra data section and unpacking its entries in ciMethodData::load_extra_data(), the last entry could contain random bogus memory.
>> It seems like the reason the last entry is not copied is because the copying of an entry requires a length which is currently calculated by taking the difference between the current entry and the next entry in the loop. But as there is no notion of a next entry when you are at the last DataLayout::arg_info_data_tag entry (because it is always the last one when present), so you can't do that. Therefore, the solution of choice seems to have been simply not copying the last DataLayout::arg_info_data_tag entry, instead of calculating what the length of that entry would be.
>> This patch appropriately calculates the length of the entries instead (which is also defined for DataLayout::arg_info_data_tag) in the copying loop, allowing the last DataLayout::arg_info_data_tag entry to be copied as well.
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8216427/webrev.00/
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8216427
>> Tested through hs-tier1-3.
>> Thanks,
>> /Erik