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

[Coleen Phillimore]

On Tue, 3 Nov 2020 14:50:36 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 3015:
> 
>> 3013:       if (tag_map != NULL && !tag_map->is_empty()) {
>> 3014:         if (num_dead_entries != 0) {
>> 3015:           tag_map->hashmap()->unlink_and_post(tag_map->env());
> 
> Why are we doing this in the callback, rather than just setting a flag?  I thought part of the point of this change was to get tagmap processing out of GC pauses.  The same question applies to the non-safepoint side.  The idea was to be lazy about updating the tagmap, waiting until someone actually needed to use it.  Or if more prompt ObjectFree notifications are needed then signal some thread (maybe the service thread?) for followup.

The JVMTI code expects the posting to be done quite eagerly presumably during GC, before it has a chance to disable the event or some other such operation.  So the posting is done during the notification because it's as soon as possible.  Deferring to the ServiceThread had two problems.  1. the event came later than the caller is expecting it, and in at least one test the event was disabled before posting, and 2. there's a comment in the code why we can't post events with a JavaThread.  We'd have to transition into native while holding a no safepoint lock (or else deadlock).  The point of making this change was so that the JVMTI table does not need GC code to serially process the table.

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

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