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

Tobias Hartmann tobias.hartmann at oracle.com
Mon Jan 14 10:17:51 UTC 2019

Hi Erik,

looks good to me too.

Best regards,

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

More information about the hotspot-compiler-dev mailing list