RFR(S): 8035841: assert(dp_src->tag() == dp_dst->tag()) failed: should be same tags 1 != 0 at ciMethodData.cpp:90 (original) (raw)

Albert Noll albert.noll at oracle.com
Fri Feb 28 12:54:37 PST 2014

I guess you ment Roland :-)

Best, Albert

Von meinem iPhone gesendet

Am 28.02.2014 um 20:03 schrieb Vladimir Kozlov <vladimir.kozlov at oracle.com>:

Hi Albert,

On 2/28/14 2:47 AM, Roland Westrelin wrote: In ciMethodData.cpp: when the ciMethodData is loaded, the code walks over the traps in the extra data to translate their Method into a ciMethod. There can be new traps added as this is happening so the code that walks over the traps should iterate over the ciMethodData copy of the profile data. Because of concurrent updates, the assert is incorrect. Loaddata() use Copy::disjointwords() to get snapshot of all data (int totalsize = datasize + extradatasize;). Whatever we add after that concurrently should not be taking into account. Can you do that, process only extradatasize extra data? I think loadextradata() should get extradatabase(), etc. from ciMethodData copy: 81 void ciMethodData::loadextradata() { 82 MethodData* mdo = getMethodData(); 83 84 // speculative trap entries also hold a pointer to a Method so need to be translated 85 DataLayout* dpsrc = mdo->extradatabase(); 86 DataLayout* endsrc = mdo->extradatalimit(); 87 DataLayout* dpdst = extradatabase();

In methodData.cpp: I had to remove the asserts because they are incorrect in case of concurrent updates as well. Also, the test that checks whether there is room for a speculative trap is broken in case of concurrent updates: the intent of nextextra(dp) is to check the next cell but if dp is allocated to a speculative trap concurrently it checks 2 cells from the current cell. Also, nextextra(dp)->tag() != DataLayout::notag doesn’t mean there’s no more space because it may have been allocated to some other trap concurrently and there may be more free space after. createifmissing is true only during deoptimization so performance is not important. So can we do update under a lock? Concurrency will screw up you in one or an other way if you don't use lock. Thanks, Vladimir http://cr.openjdk.java.net/~roland/8035841/webrev.00/ Roland.

More information about the hotspot-compiler-dev mailing list