RFR: 8216427: ciMethodData::load_extra_data() does not always unpack the last entry
Erik Österlund
erik.osterlund at oracle.com
Fri Jan 11 09:53:23 UTC 2019
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