[14] RFR(S): 8231501: VM crash in MethodData::clean_extra_data(CleanExtraDataClosure*): fatal error: unexpected tag 99

Christian Hagedorn christian.hagedorn at oracle.com
Fri Dec 13 12:46:26 UTC 2019


Hi Roland

As we have discussed offline and also in discussion with Erik Österlund, 
I propose the following alternative fix based on your suggestion:
http://cr.openjdk.java.net/~chagedorn/8231501/webrev.01/

The idea is to first snapshot the data and extra parameter data only and 
translating those. In a second step, the remaining extra data is 
prepared as before (possibly giving up the extra data lock). And only 
afterwards, when the cache is populated and no safepoints can happen 
anymore, the remaining extra data (trap entries and arg info data) is 
snapshotted and translated while holding the extra data lock. This 
ensures that no extra data is cleaned between snapshotting and 
translation since the lock is not released anymore in the meantime.

This fixes this observed concurrency bug and is probably a cleaner 
solution than the original proposed fix.

Best regards,
Christian


On 09.12.19 16:44, Roland Westrelin wrote:
> 
> Hi Christian,
> 
>> Before loading and copying the extra data from the MDO to the ciMDO in
>> ciMethodData::load_extra_data(), the metadata is prepared in a
>> fixed-point iteration by cleaning all SpeculativeTrapData entries of
>> methods whose klasses are unloaded [3]. If it encounters such a dead
>> entry it releases the extra data lock (due to ranking issues) and tries
>> again later [4]. This release of the lock triggers the bug: There can be
>> cases where one thread A is waiting in the whitebox API method to get
>> the extra data lock [2] to clean the extra data for the very same MDO
>> for which another thread B just released the lock at [4]. If that MDO
>> actually contained SpeculativeTrapData entries, then thread A cleaned
>> those but the ciMDO, which thread B is preparing, still contains the
>> uncleaned old MDO extra data (because thread B only made a snapshot of
>> the MDO earlier at [5]).
> 
> Would it be possible to call prepare_data() before the snapshot is taken
> so the snapshot doesn't contain any entry that are then removed?
> 
> Roland.
> 


More information about the hotspot-compiler-dev mailing list