RFR: 8216427: ciMethodData::load_extra_data() does not always unpack the last entry
Vladimir Kozlov
vladimir.kozlov at oracle.com
Sun Jan 13 22:11:20 UTC 2019
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
More information about the hotspot-compiler-dev
mailing list