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

[Vladimir Kozlov]

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