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

Erik Osterlund erik.osterlund at oracle.com
Mon Jan 14 11:26:23 UTC 2019

Hi Tobias,

Thanks for the review.


> On 14 Jan 2019, at 11:17, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 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

More information about the hotspot-compiler-dev mailing list