On Wed, 14 Dec 2022 15:11:55 GMT, Afshin Zafari <d...@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
