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

[Tobias Hartmann]

Hi Erik,

looks good to me too.

Best regards,
Tobias

On 11.01.19 10:53, 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