RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7]

[David Holmes]

On Wed, 14 Dec 2022 15:11:55 GMT, Afshin Zafari <duke at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiTagMapTable.cpp line 114:
>> 
>>> 112:   JvmtiTagMapKey new_entry(obj);
>>> 113:   bool is_updated = _table.put(new_entry, tag) == false;
>>> 114:   assert(is_updated, "should be updated and not added");
>> 
>> This API is confusing. You have `add` and `replace` but in product mode an `add` can `replace` and a `replace` can `add`. It isn't clear if these should be allowed rare conditions or fatal errors.
>
> I agree that this is ambigious. The `jvmtiTagMap` calls `add/update` methods of `jvmtiTagMapTable` which in turn calls `resourceHashTable` methods `put` and `put_if_absent`.
> `put` and `put_if_absent` can be used for both adding and updating and reporting it in returned values.
> `jvmtiTagMap` calls to `jvmtiTagMapTable` add/update  DO NOT CARE about the returned values. For these calls, it doesn't mater if an add (update) method resulted in an update (add). 
> So which one of the following cases would be correct?
>  - Based on the `jvmtiTagMap` calls, let the add/update be void and ignore the differences of what really happens in the table. Or
>  - Based on the `resourceHashTable` bool-valued `put` and `put_if_absent` methods, let the add/update be bool-values and leave the decision on "what really happened in the table" to the callers in `jvmtiTagMap`. (current implementation)

The issue is not the underlying RHT methods but the semantics of the `jvmtiTagMap` methods. If a call to add always expects to add then it should be a fatal error if it actually did an update as that indicates something is broken. Similarly if an update actually does an add.

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

PR: https://git.openjdk.org/jdk/pull/11288