On Tue, 3 Nov 2020 14:50:36 GMT, Kim Barrett <kbarr...@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
