RFR: 8212879: Make JVMTI TagMap table concurrent [v4]

[Coleen Phillimore]

On Tue, 3 Nov 2020 16:12:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into jvmti-table
>>  - Merge branch 'master' into jvmti-table
>>  - More review comments from Stefan and ErikO
>>  - Code review comments from StefanK.
>>  - 8212879: Make JVMTI TagMap table not hash on oop address
>
> src/hotspot/share/prims/jvmtiTagMap.cpp line 2979:
> 
>> 2977: 
>> 2978: // Concurrent GC needs to call this in relocation pause, so after the objects are moved
>> 2979: // and have their new addresses, the table can be rehashed.
> 
> I think the comment is confusing and wrong. The requirement is that the collector must call this before exposing moved objects to the mutator, and must provide the to-space invariant. (This whole design would not work with the old Shenandoah barriers without additional work. I don't know if tagmaps ever worked at all for them? Maybe they added calls to Access<>::resolve (since happily deceased) to deal with that?)  I also think there are a bunch of missing calls; piggybacking on the num-dead callback isn't correct (see later comment about that).

So the design is that when the oops have new addresses, we set a flag in the table to rehash it.  Not sure why this is wrong and why wouldn't it work for shenandoah? @zhengyu123 ?  When we call WeakHandle.peek()/resolve() after the call, the new/moved oop address should be returned.  Why wouldn't this be the case?

-------------

PR: https://git.openjdk.java.net/jdk/pull/967