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