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

[Coleen Phillimore]

On Tue, 3 Nov 2020 16:17:58 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 127:
> 
>> 125:   // The table cleaning, posting and rehashing can race for
>> 126:   // concurrent GCs. So fix it here once we have a lock or are
>> 127:   // at a safepoint.
> 
> I think this comment and the one below about locking are confused, at least about rehashing.  I _think_ this is referring to concurrent num-dead notification?  I've already commented there about it being a problem to do the unlink &etc in the GC pause (see later comment).  It also seems like a bad idea to be doing this here and block progress by a concurrent GC because we're holding the tagmap lock for a long time, which is another reason to not have the num-dead notification do very much (and not require a lock that might be held here for a long time).

The comment is trying to describe the situation like:
1. mark-end pause (WeakHandle.peek() returns NULL because object A is unmarked)
2. safepoint for heap walk
   2a. Need to post ObjectFree event for object A before the heap walk doesn't find object A.
3. gc_notification - would have posted an ObjectFree event for object A if the heapwalk hadn't intervened

The check_hashmap() function also checks whether the hash table needs to be rehashed before the next operation that uses the hashtable.

Both operations require the table to be locked.

The unlink and post needs to be in a GC pause for reasons that I stated above.  The unlink and post were done in a GC pause so this isn't worse for any GCs.  The lock can be held for concurrent GC while the number of entries are processed and this would be a delay for some applications that have requested a lot of tags, but these applications have asked for this and it's not worse than what we had with GC walking this table in safepoints.

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

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